Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Well, it is. If the data integrity was done with a system trigger
> created at table creation time the firing order is relevant.
Right, but the data integrity check is _not_ done via a system
trigger. Hence, "trigger firing order is irrelevant to the o
Neil Conway wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
I don't know how the check for the data integrity is implemented but if
is a trigger
It isn't -- trigger firing order is irrelevant to the original
question.
Well, it is. If the data integrity was done with a system trigger
created
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> I don't know how the check for the data integrity is implemented but if
> is a trigger
It isn't -- trigger firing order is irrelevant to the original
question.
> 1) Create table
> 2) create a before insert trigger: trigger_a
> 3) create a before ins
On Mon, Nov 10, 2003 at 21:48:30 +0100,
Gaetano Mendola <[EMAIL PROTECTED]> wrote:
> Seems to me too, from the standard:
>
> "The order of execution of a set of triggers is ascending by value of
> their timestamp of creation in their
> descriptors, such that the oldest trigger executes first. I
Neil Conway <[EMAIL PROTECTED]> writes:
> Are there plans for a 7.3.5 release?
Yes, I think there will be a 7.3.5 fairly soon.
> If not, we needn't worry about
> it, IMHO. But if there are, I can take a look at producing a low-risk
> version of this changed for application to REL7_3_STABLE.
Go f
Neil Conway wrote:
Thomas Erskine <[EMAIL PROTECTED]> writes:
A before trigger doesn't always fire. If a column being inserted into is
too small for the incoming data, psql complains:
ERROR: value too long for type ...
without giving the trigger procedure a chance to deal with it.
I belie
Tom Lane <[EMAIL PROTECTED]> writes:
> Well, it was done as part of a significant set of changes to
> pg_dumpall:
Are there plans for a 7.3.5 release? If not, we needn't worry about
it, IMHO. But if there are, I can take a look at producing a low-risk
version of this changed for application to REL
Neil Conway <[EMAIL PROTECTED]> writes:
> Is this a candidate for being back-patched to 7_3_STABLE? IMHO it
> would be useful and low-risk.
Well, it was done as part of a significant set of changes to pg_dumpall:
2003-05-30 18:55 tgl
* src/bin/pg_dump/: dumputils.c, dumputils.h, pg_dump
Tom Lane <[EMAIL PROTECTED]> writes:
> Paul Tillotson <[EMAIL PROTECTED]> writes:
>> pg_dumpall does not save all access control permissions on a database.
>> (This is true for at least the CREATE permission.)
>
> This is fixed as of 7.4.
Is this a candidate for being back-patched to 7_3_STABLE? I
"Przemysław" <[EMAIL PROTECTED]> writes:
> Hello
> I dont know is this a bug but when I use COPY to load data into table
> sequence of the primary key in this table have always start value =
> 1.
Doesn't sound like a bug. If the input data for COPY does not include
PK values, you should not includ
Thomas Erskine <[EMAIL PROTECTED]> writes:
> A before trigger doesn't always fire. If a column being inserted into is
> too small for the incoming data, psql complains:
> ERROR: value too long for type ...
> without giving the trigger procedure a chance to deal with it.
I believe this is a
>Apparently, the implementation of that function contains a bug in the
>memory handling.
oops - found it. String allocation was 1 byte short. Thanks.
Robert
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
12 matches
Mail list logo
