On Fri, Jan 30, 2009 at 03:12:27PM -0500, Merlin Moncure wrote:
> On 1/30/09, Sam Mason <sam@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/
