From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | using composite types in insert/update |
Date: | 2009-01-28 17:03:56 |
Message-ID: | b42b73150901280903kee75173nafd9393fb24f3a17@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
IMO, composite types on insert/update should work as they do on select:
SELECT foo FROM foo; -- works, returning type foo
INSERT INTO foo VALUES '(something)'::foo -- fails,
but we have a workaround:
INSERT INTO foo SELECT ('(something)'::foo).* -- expands foo into foo columns
however no such workaround exists for update. ideally,
UPDATE foo SET foo = foo;
would be valid. Aside from fixing a surprising behavior, it would
greatly aid in writing triggers that do things like ship updates over
dblink _much_ easier (in fact...the dblink_build_xxx family would
become obsolete).
e.g.
perform dblink.dblink('UPDATE foo SET foo = \'' || new || '\'::foo);
I call the existing behavior of insert/update of composite types
broken to the point of almost being a bug. Fixing the above to work
would close the loop on a broad new set of things you can do with
composite types.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-28 17:35:42 | Re: 8.4 release planning |
Previous Message | Tom Lane | 2009-01-28 17:00:15 | Re: pg_upgrade project status |