FAQ
Here's what I thought to be an odd result from the 7.0beta3 parser...

create table foo (id serial, h_count integer);
insert into foo (h_count) values (10);
create table temp_foo as select * from foo;
drop table foo;
drop sequence foo_id_seq;
create table foo (id serial, h_count integer);
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?

Regards,
Ed Loehr

Search Discussions

  • Tom Lane at May 25, 2000 at 4:29 pm

    Ed Loehr 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
  • Andreas Zeugswetter at May 26, 2000 at 6:40 am

    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.
    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?
    This feature is sacrosanct for me, if you ripp it, you take away the
    feature to add calculated columns to tables.

    The important part for me, is that foo.calcit calls the function calcit(foo).

    Andreas

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 25, '00 at 3:35p
activeMay 26, '00 at 6:40a
posts3
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase