Skip site navigation (1) Skip section navigation (2)

Re: using composite types in insert/update

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Sam Mason <sam(at)samason(dot)me(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: using composite types in insert/update
Date: 2009-01-30 21:47:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

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.


In response to


pgsql-hackers by date

Next:From: Merlin MoncureDate: 2009-01-30 21:50:14
Subject: Re: using composite types in insert/update
Previous:From: Bruce MomjianDate: 2009-01-30 21:41:22
Subject: Re: How to get SE-PostgreSQL acceptable

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group