Re: parser oddity (t.count)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ed Loehr <eloehr(at)austin(dot)rr(dot)com>
Cc: pghackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: parser oddity (t.count)
Date: 2000-05-25 16:28:40
Message-ID: 23194.959272120@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ed Loehr <eloehr(at)austin(dot)rr(dot)com> writes:
> insert into foo (id, h_count) select t.id, t.count from temp_foo t;

> ERROR: Attribute t.id must be GROUPed or used in an aggregate function

> I mislabeled the 't.h_count' column in my INSERT statement as 't.count',
> and what I found strange was that the parser evidently thinks t.count is
> an aggregate. Is 't.count' valid use/syntax for an aggregate?

Hmm. Due to some ancient Postquel features that you probably don't want
to hear about, foo.bar and bar(foo) are considered near-equivalent
notations by the parser. It looks like when it couldn't find 'count' as
a field name, it tried and succeeded to interpret it as a function call
instead.

(A contributing problem here is that the parser is absolutely lax about
what it will take as the argument of count(). IMHO you should have
gotten something like "Unable to select an aggregate function
count(unknown)", which might have been a little less confusing.)

It works in the other direction too: field(foo) will be interpreted as
foo.field if foo has a column named field.

This equivalence can be pretty confusing if you don't know about it, but
I'm hesitant to suggest ripping it out because of the risk of breaking
old applications. Anyone have strong opinions one way or the other?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-05-25 16:40:47 Re: Create user/create database outside template1
Previous Message Zeugswetter Andreas SB 2000-05-25 16:24:57 AW: AW: AW: More Performance