Re: Getting rid of aggregate_dummy()

From: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Getting rid of aggregate_dummy()
Date: 2020-11-02 15:39:04
Message-ID: CAMsGm5cMQwh9uUmypvVE78VQ0C2Y0QOkU8h4NW5+oCZ-gNEJVQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2 Nov 2020 at 09:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Isaac Morland <isaac(dot)morland(at)gmail(dot)com> writes:
>

> > Speaking as somebody who sometimes does really dumb things, I don’t like
> > this change in error message. The current message clearly identifies the
> > problem; the new message makes it look like there is a bug in Postgres.
>
> Neither message would be reachable without (erroneous) C hacking,
> so I don't quite buy that there's a problem.
>

OK, I must have misunderstood. I had the impression that we were talking
about just writing a query which used an aggregate function where a normal
function was needed, but on closer consideration I see I had it wrong. For
example:

odyssey=> select * from uw_term where count(*) = 1;
ERROR: aggregate functions are not allowed in WHERE
LINE 1: select * from uw_term where count(*) = 1;
^
odyssey=>

But this is a different error message, and thinking about it putting an
aggregate in the SELECT will end up using it as an aggregate (e.g. SELECT
count(*) FROM ...).

I agree that C hackers need to know what they’re doing ;-)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2020-11-02 15:39:10 Re: public schema default ACL
Previous Message Magnus Hagander 2020-11-02 15:35:23 Re: Disable WAL logging to speed up data loading