On 1/30/09, Merlin Moncure wrote:
> 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
thinko:
select f from foo f; -- this is how it really works now
merlin
--
Sent via pgsql-hackers mailing list (p
On 1/30/09, Sam Mason 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
fi
On Fri, Jan 30, 2009 at 03:45:54PM -0500, Merlin Moncure wrote:
> On 1/30/09, Sam Mason wrote:
> > 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.
>
> hm. i don't think so...at
On Fri, Jan 30, 2009 at 03:29:29PM -0500, Andrew Chernow wrote:
> Sam Mason wrote:
> >On Fri, Jan 30, 2009 at 02:47:49PM -0500, Merlin Moncure wrote:
> >>On 1/30/09, Tom Lane wrote:
> >>>Merlin Moncure writes:
> >>> > You are missing the point, using the composite type allows you to
> >>> > build
On 1/30/09, Sam Mason wrote:
> On Fri, Jan 30, 2009 at 03:12:27PM -0500, Merlin Moncure wrote:
> > On 1/30/09, Sam Mason 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
> > > befor
On Fri, Jan 30, 2009 at 03:12:27PM -0500, Merlin Moncure wrote:
> On 1/30/09, Sam Mason 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 c
Sam Mason wrote:
On Fri, Jan 30, 2009 at 02:47:49PM -0500, Merlin Moncure wrote:
On 1/30/09, Tom Lane wrote:
Merlin Moncure writes:
> You are missing the point, using the composite type allows you to
> build the insert without knowing the specific layout of the
> table...
Surely at *some*
On 1/30/09, Sam Mason 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).
w
On Fri, Jan 30, 2009 at 02:47:49PM -0500, Merlin Moncure wrote:
> On 1/30/09, Tom Lane wrote:
> > Merlin Moncure writes:
> > > You are missing the point, using the composite type allows you to
> > > build the insert without knowing the specific layout of the
> > > table...
> >
> > Surely at *s
On 1/30/09, Tom Lane wrote:
> Merlin Moncure writes:
> > You are missing the point, using the composite type allows you to
> > build the insert without knowing the specific layout of the
> > table...
>
> Surely at *some* level you have to know that.
You don't (if I understand your meaning) ..
On Fri, Jan 30, 2009 at 11:01:53AM -0500, Merlin Moncure wrote:
> On 1/30/09, Sam Mason wrote:
> > The VALUES command is just a convenient way of getting lots of tuples
> > into PG isn't it? If the above was valid, PG would have to support
> > similar syntax elsewhere, which seems independent o
Merlin Moncure writes:
> You are missing the point, using the composite type allows you to
> build the insert without knowing the specific layout of the
> table...
Surely at *some* level you have to know that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pg
On 1/30/09, Sam Mason wrote:
> On Wed, Jan 28, 2009 at 12:03:56PM -0500, Merlin Moncure wrote:
> > IMO, composite types on insert/update should work as they do on select:
>
> The VALUES command is just a convenient way of getting lots of tuples
> into PG isn't it? If the above was valid, PG wou
On Wed, Jan 28, 2009 at 12:03:56PM -0500, Merlin Moncure wrote:
> IMO, composite types on insert/update should work as they do on select:
> INSERT INTO foo VALUES '(something)'::foo -- fails,
The VALUES command is just a convenient way of getting lots of tuples
into PG isn't it? If the above was
Merlin Moncure wrote:
> however no such workaround exists for update. ideally,
> UPDATE foo SET foo = foo;
+1.
"UPDATE foo SET (*) = (foo.*)" would be another candidate of syntax.
I want to use this kind of queries to apply a changeset log
to another table. It is just like log application in S
IMO, composite types on insert/update should work as they do on select:
SELECT foo FROM foo; -- works, returning type foo
INSERT INTO foo VALUES '(something)'::foo -- fails,
but we have a workaround:
INSERT INTO foo SELECT ('(something)'::foo).* -- expands foo into foo columns
however no such
16 matches
Mail list logo
