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. > 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. > Record *types* are most definitely not first class objects; > record/composite *values* on the other hand have been gaining support well, I used the terms record types and composite types interchangeably in this discussion. Sorry for the confusion. I don't know if you are arguing for or against the idea of 'update foo set foo = foo' working. (if against, why?) merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
