Re: using composite types in insert/update

On 1/30/09, Sam Mason <sam(at)samason(dot)me(dot)uk> wrote:
> But why not just leave INSERT as it is, it works and is unambiguous!

Because *there is no way to insert a composite type!!!* (you can
expand the type via INSERT ... SELECT, but not for UPDATE).

SELECT foo FROM foo; pulls the foo composite from the table, not the
fields. I still can't understand why you want to not be able to do
this via insert. You are looking for more flexible way to imput
fields, I am looking for a way to input type directly.

> But why is this better than using a *?

because we are not updating specific fields...'*' denotes 'all
columns'. we are setting the type to something else. I want to
update the type directly, not it's fields, because I don't want to
construct the update statement.

(*) is better than *, because at least we are suggesting a composite.
However, let's try and keep the syntax a little regular?

select foo from foo; -- this is how it works now
update foo set foo=somefoo; --why would you want update to work any
way but this way?

likewise, with aliases
select foo f from foo; -- this is how it works now
update foo f set f=somefoo; -- again, this is how it should work

my only point was that there is no aliases in inserts, so there is a
minute probability of case where you can't insert the composite type
directly.

your idea (i think):
update foo f set (*) = somefoo; is a huge departure in syntax and
semantics from the way things work in other places.

merlin