From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RETURNING and DO INSTEAD ... Intentional or not? |
Date: | 2007-09-12 18:40:46 |
Message-ID: | 25140.1189622446@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Richard Huxton <dev(at)archonet(dot)com> writes:
> Tom Lane wrote:
>> What the RETURNING clause in the rule does is let you define the data
>> that should be returned if the rewritten INSERT had a returning clause
>> to start with.
> Sorry - haven't got a CSV download here, or I'd check myself. Does this
> just allow an INSERT...RETURNING inside the rule, or could it be
> something like:
> CREATE RULE ... AS ON INSERT ... DO INSTEAD SELECT f(NEW.test1);
Well, that's what you do if you want to deliberately break the normal
behavior of INSERT, ie, have it fire back data unconditionally.
What the rule definition of RETURNING is intended for is to let you
write rules that support an updatable view that does the right things,
ie INSERT and INSERT RETURNING on the view both do what you'd expect
them to do if the view were a plain table.
Josh, this *is* documented; see the CREATE RULE reference page for full
details, and there's at least passing references here:
http://developer.postgresql.org/pgdocs/postgres/rules-update.html#RULES-UPDATE-VIEWS
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2007-09-12 18:51:24 | Re: RETURNING and DO INSTEAD ... Intentional or not? |
Previous Message | Tom Lane | 2007-09-12 18:30:02 | Representation of redirected line pointers in HOT |