The whole early security business looks like a mess :-(. I suspect
you should rip all that out of the backend and add a step to initdb
that fills in those tables.
I also think early security codes are ad-hoc. :-(
Pushing it into initdb seems me a good idea.
I'll try to consider whether it
On Wed, May 07, 2008 at 03:04:49PM -0700, David Fetter wrote:
1. Create a generic (possibly overloaded) trigger function, bundled
with PostgreSQL, which sets a field to some value. For example, a
timestamptz version might set the field to now().
Doesn't the SQL standard GENERATED BY
Hi,
we have been running our own heavily modified/enhanced version of dbmirror,
running on 7.4 for some years,
and now it is the time to upgrade to 8.3.
We have called our approach Conditional row grained + FK dependency oriented
lazy replication, that is,
any FK dependencies of a row are
Martijn van Oosterhout írta:
On Wed, May 07, 2008 at 03:04:49PM -0700, David Fetter wrote:
1. Create a generic (possibly overloaded) trigger function, bundled
with PostgreSQL, which sets a field to some value. For example, a
timestamptz version might set the field to now().
Doesn't
Zoltan Boszormenyi írta:
Martijn van Oosterhout írta:
On Wed, May 07, 2008 at 03:04:49PM -0700, David Fetter wrote:
1. Create a generic (possibly overloaded) trigger function, bundled
with PostgreSQL, which sets a field to some value. For example, a
timestamptz version might set the field
On Wed, 2008-04-30 at 16:58 +0100, Simon Riggs wrote:
The main query will then look like this
select target.ctid
,case when-not-matched (as above)
,case when-matched (as above)
,(all other columns required for side queries)
from source-query left outer join
Tom, did we come to any conclusion on this?
---
Tom Lane wrote:
Whilst fooling with bug #4058 I noticed that xml2's .c files were being
compiled without -g or any of the various warning flags we normally use.
I saw this:
On Thursday 08 May 2008 00:27:10 Tino Wildenhain wrote:
David Fetter wrote:
Folks,
A co-worker pointed out to me that MySQL has a feature that, properly
implemented and maybe extended, could be handy, namely what MySQL
calls a timestamp field, so here's a proposal:
1. Create a
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, did we come to any conclusion on this?
No, nobody suggested anything :-(
As I said, I think we can just drop the assignment to CFLAGS in HEAD
and 8.3, relying on configure to get it right.
After looking at the pgxs documentation, I think that the
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, are you intending to remove this part of the sort code?
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
Well, I got some push-back on the proposal, so I'd kind of dropped it.
But AFAIR the objections were purely hypothetical, whereas the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, are you intending to remove this part of the sort code?
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
Well, I got some push-back on the proposal, so I'd kind of dropped it.
But AFAIR the objections were purely
Patch applied (yea!).
---
Bruce Momjian wrote:
Bruce Momjian wrote:
Updated patch with clearer documentation that matches the above
behavior:
ftp://momjian.us/pub/postgresql/mypatches/wrap
I found a bug in
At the backend, I'm measuring the cost of executing (via SPI_execute_plan)
the read-only plan of a simple query with no reference to tables. E.g.
simpleplan(int) AS SELECT $1 5
Executing this plan via SPI_execute takes around 70% more time than
directly executing the relevant operator
Luis Vargas [EMAIL PROTECTED] writes:
At the backend, I'm measuring the cost of executing (via SPI_execute_plan)
the read-only plan of a simple query with no reference to tables. E.g.
simpleplan(int) AS SELECT $1 5
Executing this plan via SPI_execute takes around 70% more time than
DF,
2. Have some kind of pre-processing of CREATE and ALTER statements on
tables which would attach the above function to the field at hand,
something like:
CREATE TABLE foo(
last_updated TIMESTAMPTZ_UPDATED(),
So you're suggesting a user-definable version of SERIAL?
--
Josh Berkus
Matt,
Patches are an integral part of the conversation about development, I
think trying to split them up is awkward at best. Do people really
still think that the potential for larger messages is really a problem?
Well, I for one would need to change my subscription address. This
Josh Berkus [EMAIL PROTECTED] writes:
How about hacking together a simple patch tracker instead, as Bruce
suggested?
I've never found e-mail to be a particularly good way to track patches.
The thing is that we don't just want to track patches. We want to talk about
patches.
In my ideal
The recent xml2 build changes have broken MSVC builds.
The problem is this fragment (that appears twice) from
src/tools/msvc/Mkvcbuild.pm:
foreach my $o (split /\s+/, $1)
{
$o =~ s/\.o$/.c/;
$proj-AddFile('contrib\\' . $n . '\\' . $o);
}
which gets
On Fri, May 9, 2008 at 4:38 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
No, we don't change behaviors in back branches unless we get lots of
complaints, and we haven't in this case.
I suspect it's annoying for a lot of people, just not annoying enough
to make them complain about it.
I
Guillaume Smet wrote:
On Fri, May 9, 2008 at 4:38 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
No, we don't change behaviors in back branches unless we get lots of
complaints, and we haven't in this case.
I suspect it's annoying for a lot of people, just not annoying enough
to make them
20 matches
Mail list logo
