Yes. In my case I want the history gone too. Keeping the history wouldn't
hurt, but it's just a preference.
If I did keep the history I definitely don't want that last UPDATE where E is
set null... but that's easily circumvented via the trigger.
Thanks for the pointer to look for the other pa
Nm, I think I see what is happening.
I started tracing the transaction and see that another high level object, when
deleted, does an ON DELETE SET NULL, then the item updated is deleted. So the
AFTER UPDATE is run for the row.. even though it's a deleted row later in the
sequence...
So it l
I can upload the whole schema someplace, or is attaching a few files here okay?
Noticed that if I delete from the feature level, I do not hit the problem.
---
Stephen Cuppett
SAS® Certified Advanced Programmer for
Stephen Cuppett <[EMAIL PROTECTED]> writes:
> When A is deleted, B is deleted, E is set null. Then, D is deleted and E is
> deleted.
> FOR EVERY ROW AFTER UPDATE is run on E for rows that no longer exist.
> Not sure if that's a bug or not... not sure it would be undesirable under
> conditions
I wrote:
> "Rudolf Leitgeb" <[EMAIL PROTECTED]> writes:
>> - Compile psql for x86_64. This can be easily done with the following
>> commands:
>> CFLAGS="-Os -arch x86_64" LDFLAGS="-arch x86_64" ./configure
>> --disable-depend --with-pam --with-openssl
>> --prefix=/Users/rleitgeb/pq_x86_64
> I d
Stephen Cuppett <[EMAIL PROTECTED]> writes:
> I can upload the whole schema someplace, or is attaching a few files here
> okay?
What would be easiest from this end is a SQL script to create the
tables, insert any test data needed, and then reproduce the problem,
starting from an empty database.
"Rudolf Leitgeb" <[EMAIL PROTECTED]> writes:
> - Compile psql for x86_64. This can be easily done with the following
> commands:
> CFLAGS="-Os -arch x86_64" LDFLAGS="-arch x86_64" ./configure
> --disable-depend --with-pam --with-openssl
> --prefix=/Users/rleitgeb/pq_x86_64
I don't think it's re
"Stephen Cuppett" <[EMAIL PROTECTED]> writes:
> Description:Trigger event fired "UPDATE" when "DELETE" happening via
> foreign key
You're going to need to show a complete example if you want any help
with this. (My bet is that you've overlooked a trigger someplace...)
Rudolf Leitgeb escreveu:
> - Compile psql for x86_64. This can be easily done with the following
> commands:
>
> CFLAGS="-Os -arch x86_64" LDFLAGS="-arch x86_64" ./configure
> --disable-depend --with-pam --with-openssl
> --prefix=/Users/rleitgeb/pq_x86_64
>
Are you using libedit, right? What is
The following bug has been logged online:
Bug reference: 4397
Logged by: Rudolf Leitgeb
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: OSX Leopard
Description:crash in tab-complete.c
Details:
When I compiled postgresql for different tar
The following bug has been logged online:
Bug reference: 4396
Logged by: Stephen Cuppett
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: RHEL5.2 x86_64
Description:Trigger event fired "UPDATE" when "DELETE" happening via
foreign key
Detail
Yes, you are right, with record type working correct;
Thanks
2008/9/2 Tom Lane <[EMAIL PROTECTED]>
> "Oleg Serov" <[EMAIL PROTECTED]> writes:
> > But if there are some records in t_table and we romove WHERE 1=0, we will
> > have
> > ERROR: wrong record type supplied in RETURN NEXT CONTEXT: PL/pgS
The following bug has been logged online:
Bug reference: 4395
Logged by: Daniel
Email address: [EMAIL PROTECTED]
PostgreSQL version: postgresql-8.3.
Operating system: Windows Vista
Description:internal account lookup faulure
Details:
what i have do?
--
Sent via pg
13 matches
Mail list logo
