Tom Lane wrote:
Richard Huxton <dev@archonet.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 ...
I can live with that, so long as there's no
extremely-clever-look-inside-plpgsql feature anyone is planning.
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
