I'll fix it this way:
CREATE TABLE foob(id serial primary key, name varchar default '');
CREATE TABLE fooA(id serial primary key, fooBook int not null
references fooB(id) on update cascade on delete cascade DEFERRABLE,
name varchar default '');
CREATE FUNCTION foobarrB() RETURNS trigger AS
$_$
B
it is slightly more complicated than that, cos I need information from
fooA too. So we have a chicken and egg problem.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thursday 24 June 2010 7:40:22 am Grzegorz Jaśkiewicz wrote:
> that Id refers to 'name' column that I need. There still is FK on it,
> so basically it is broken inside transaction, from trigger's
> perspective.
I understand this part. What I am saying is think about reversing your point of
view
that Id refers to 'name' column that I need. There still is FK on it,
so basically it is broken inside transaction, from trigger's
perspective.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-gene
On Thursday 24 June 2010 7:21:04 am Grzegorz Jaśkiewicz wrote:
> because in my case I have many tables with FK pointing at foob. So
> writing that many triggers is going to be a royal pain.
I am trying to see how this is different from writing the triggers on the child
tables :) In any case are t
because in my case I have many tables with FK pointing at foob. So
writing that many triggers is going to be a royal pain.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thursday 24 June 2010 1:48:12 am Grzegorz Jaśkiewicz wrote:
> On Wed, Jun 23, 2010 at 7:31 PM, Tom Lane wrote:
> > Thom Brown writes:
> >> Yes, I'm still not exactly sure why it's seeing uncommitted changes. :/
> >
> > Because it's all one transaction. A transaction that couldn't see its
> >
On Wed, Jun 23, 2010 at 7:31 PM, Tom Lane wrote:
> Thom Brown writes:
>> Yes, I'm still not exactly sure why it's seeing uncommitted changes. :/
>
> Because it's all one transaction. A transaction that couldn't see its
> own changes wouldn't be very useful.
>
> I think what the OP is unhappy abo
On 06/23/2010 08:22 AM, Grzegorz Jaśkiewicz wrote:
the delete will succeed.
That's not the point of the exercise tho.
The point, is to print name in trigger, rather than null!
Sorry about the noise, I completely missed what you where getting at.
--
Adrian Klaver
adrian.kla...@gmail.com
--
Sen
Thom Brown writes:
> Yes, I'm still not exactly sure why it's seeing uncommitted changes. :/
Because it's all one transaction. A transaction that couldn't see its
own changes wouldn't be very useful.
I think what the OP is unhappy about is that he imagines that the ON
CASCADE DELETE action is p
2010/6/23 Grzegorz Jaśkiewicz :
> I do understand what you are saying, but still it is highly
> unintuitive. Since trigger is BEFORE, developer will expect that data
> to be there.
>
Yes, I'm still not exactly sure why it's seeing uncommitted changes. :/
Thom
--
Sent via pgsql-general mailing l
I do understand what you are saying, but still it is highly
unintuitive. Since trigger is BEFORE, developer will expect that data
to be there.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-gener
2010/6/23 Grzegorz Jaśkiewicz :
> it is confusing to me, because I thought triggers are firring BEFORE
> anything goes away. So I assume that all data is still going to be
> visible to the trigger, as it is firing BEFORE. The only thing is, it
> looks like the FKs are doing the deletion and than th
2010/6/23 Grzegorz Jaśkiewicz :
> the delete will succeed.
> That's not the point of the exercise tho.
>
> The point, is to print name in trigger, rather than null!
>
But if it's been deleted from foob already, how can it print it?
So if foob has a row with an id of 5, then:
DELETE FROM foob WHER
it is confusing to me, because I thought triggers are firring BEFORE
anything goes away. So I assume that all data is still going to be
visible to the trigger, as it is firing BEFORE. The only thing is, it
looks like the FKs are doing the deletion and than things are handed
over to triggers.
--
S
2010/6/23 Grzegorz Jaśkiewicz :
> well, change foob column name to something else, and try yourself. It
> still fails.
>
Wait a minute... it's deleting from foob, which is considered deleted
for the remainder of that transaction. This cascades to fooa which
sets off the trigger before it does any
the delete will succeed.
That's not the point of the exercise tho.
The point, is to print name in trigger, rather than null!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wednesday 23 June 2010 7:57:22 am Grzegorz Jaśkiewicz wrote:
> well, change foob column name to something else, and try yourself. It
> still fails.
As I said in my previous post it did not fail on my instance of 8.3.7. In other
words the DELETE succeeded. At this point I do not have an explana
well, change foob column name to something else, and try yourself. It
still fails.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wednesday 23 June 2010 7:02:59 am Grzegorz Jaśkiewicz wrote:
> nope, that's not the thing. This is just specific to my example. But
> production code I have, doesn't have such confusing name, and still
> fails.
> Plus postgresql doesn't rely on names, but on oids rather.
For what it worth I tri
On Wednesday 23 June 2010 5:35:52 am Grzegorz Jaśkiewicz wrote:
> consider following example:
>
>
>
> CREATE TABLE foob(id serial primary key, name varchar default '');
> CREATE TABLE fooA(id serial primary key, fooB int not null references
> fooB(id) on update cascade on delete cascade, name varch
not really, as it depends on pretty much both tables.
This is where de-normalization would actually makes sens, except for
that it wouldn't - because it will badly effect all my other queries
(joining on varchar is so slow).
I could drop FK, and replace that with my own trigger(s), but that's a
lo
2010/6/23 Grzegorz Jaśkiewicz :
> any ideas than, how can make it actually do what I wanted it to do please ?
> Making FK deferrable doesn't help.
>
>
> thanks.
>
Is it practical to put the trigger on the other table instead?
Thom
--
Sent via pgsql-general mailing list (pgsql-general@postgresql
nope, that's not the thing. This is just specific to my example. But
production code I have, doesn't have such confusing name, and still
fails.
Plus postgresql doesn't rely on names, but on oids rather.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
any ideas than, how can make it actually do what I wanted it to do please ?
Making FK deferrable doesn't help.
thanks.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/6/23 Grzegorz Jaśkiewicz :
> this is 8.3.7, for the record. And no, They won't let me update it to 8.3.11
> :/
>
Well, same applies:
http://www.postgresql.org/docs/8.3/static/sql-createtrigger.html
I've just run the same set of statements you specified against 8.4.1,
8.4.4 and 9.0 beta2 and
this is 8.3.7, for the record. And no, They won't let me update it to 8.3.11 :/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/6/23 Grzegorz Jaśkiewicz :
> consider following example:
>
>
>
> CREATE TABLE foob(id serial primary key, name varchar default '');
> CREATE TABLE fooA(id serial primary key, fooB int not null references
> fooB(id) on update cascade on delete cascade, name varchar default
> '');
>
> CREATE FUN
consider following example:
CREATE TABLE foob(id serial primary key, name varchar default '');
CREATE TABLE fooA(id serial primary key, fooB int not null references
fooB(id) on update cascade on delete cascade, name varchar default
'');
CREATE FUNCTION foobarrA() RETURNS trigger AS
$_$
BEGIN
29 matches
Mail list logo
