From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: View updating and nextval() workaround - will this ever break? |
Date: | 2006-10-31 15:02:23 |
Message-ID: | 29068.1162306943@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:
> Basically, I'm wondering if anyone can see a problem with my standard
> workaround to the macro-expansion-vs-nextval problem with view.
> CREATE FUNCTION foobar_ins_fn(p_f1 int4, p_b1 int4) RETURNS void AS $$
> BEGIN
> INSERT INTO foo (f_id, f1) VALUES (nextval('foo_f_id_seq'), p_f1);
> INSERT INTO bar (f_id, b1) VALUES (currval('foo_f_id_seq'), p_b1);
> END;
> $$ LANGUAGE plpgsql;
> CREATE RULE foobar_good_ins AS ON INSERT TO foobar_good
> DO INSTEAD SELECT foobar_ins_fn(NEW.f1, NEW.b1);
The main problem with this is that instead of an "INSERT n" command
completion response, you'll get back a useless SELECT result and then
"INSERT 0" (because the original INSERT was suppressed by the INSTEAD
rule). If your application can deal with that, it's OK, but some don't
like it ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-31 15:06:40 | Re: [HACKERS] WAL logging freezing |
Previous Message | Joshua D. Drake | 2006-10-31 14:42:23 | Re: [HACKERS] Index greater than 8k |