On Fri, Jan 30, 2009 at 03:12:27PM -0500, Merlin Moncure wrote: > On 1/30/09, Sam Mason <s...@samason.me.uk> wrote: > > quite often (i.e. a VALUES command with many singletons). This seems > > a bit annoying and appears to be what you were suggesting you wanted > > before (although you killed the relevant bit of context, making me think > > we may be talking about different things). > > we are. See the title of the thread: 'using composite types in > insert/update'. that's what I'm talking about. I especially am not > talking about the 'values' statement.
Humm, I was talking about your example code: INSERT INTO foo VALUES '(something)'::foo; This isn't currently valid, but it sounds as though it needs to be. > > For several reasons; mainly because SQL is an abortion of a language, > > it's got no regularity and attempts to justify requirements because of > > "symmetry" will end up causing more headaches. > > > > Another way of saying what you seem to be saying above is: I want things > > to work correctly, unless I happen to have a column name that happens to > > be the same as the table at which point I want everything to break. > > Upthread, I noted the usefulness in writing triggers. There are many > other uses. btw, symmetry (making insert work more similarly to > select) is tangential but surely a good thing. > I don't know if you are arguing for or against the idea of 'update foo > set foo = foo' working. (if against, why?) I agree that the mechanism is good, it's just that the syntax you proposed comes with it's own built in footgun. Symmetry is also muddied by the fact that SELECT and INSERT/UPDATE are built on fundamentally different premises. It's only ever possible to modify a set of rows from one table at a time, whereas a SELECT is designed to work with multiple tables. -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
