On Fri, Oct 17, 2014 at 10:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Merlin Moncure <mmonc...@gmail.com> writes: >> On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I think it wouldn't; Merlin is proposing that f would be taken as the >>> field name. A more realistic objection goes like this: >>> >>> create table foo(f int, g int); >>> update foo x set x = (1,2); -- works >>> alter table foo add column x int; >>> update foo x set x = (1,2,3); -- no longer works >>> >>> It's not a real good thing if a column addition or renaming can >>> so fundamentally change the nature of a query. > >> That's exactly how SELECT works. I also dispute that the user should >> be surprised in such cases. > > Well, the reason we have a problem in SELECT is that we support an > unholy miscegenation of SQL-spec and PostQUEL syntax: the idea that > "SELECT foo FROM foo" could represent a whole-row selection is nowhere > to be found in the SQL standard, for good reason IMO. But we've never > had the courage to break cleanly with this Berkeley leftover and > insist that people spell it SQL-style as "SELECT ROW(foo.*) FROM foo". > I'd just as soon not introduce the same kind of ambiguity into UPDATE > if we have a reasonable alternative.
Ah, interesting point (I happen to like the terse syntax and use it often). This is for posterity anyways since you guys seem to like Atri's proposal, which surprised me. However, I think you're over simplifying things here. Syntax aside: I think SELECT f FROM foo f; and a hypothetical SELECT row(f.*) FROM foo f; give different semantics. The former gives an object of type 'f' and the latter gives type 'row'. To get parity, you'd have to add an extra cast which means you'd have to play tricky games to avoid extra performance overhead besides being significantly more verbose. I'm aware some of the other QUELisms are pretty dodgy and have burned us in the past (like that whole function as record reference thing) but pulling a record as a field in select is pretty nice. It's also widely used and quite useful in json serialization. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
