Re: View with duplicate GROUP BY entries

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: View with duplicate GROUP BY entries
Date: 2017-11-21 18:11:33
Message-ID: 12820.1511287893@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Nov 21, 2017 at 12:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yeah, we probably ought to make more of an effort to regenerate the
>> original query wording. I do not think that forcing positional notation
>> is a suitable answer in this case, because it would result in converting
>> SQL-standard queries to nonstandard ones.

> Who cares? The other end is presumptively PostgresSQL, because this
> is postgres_fdw.

No, you missed the context. Yes, the original problem is in postgres_fdw,
and there indeed it seems fine to emit GROUP BY 1,2. What Ashutosh is
pointing out is that ruleutils.c can emit a representation of a view
that fails to preserve its original semantics, thus causing dump/reload
problems that have nothing at all to do with FDWs. And what I'm pointing
out is that we don't like pg_dump to emit nonstandard representations
of objects that were created with perfectly standard-compliant queries;
therefore emitting GROUP BY 1,2 isn't good if the query wasn't spelled
like that to begin with.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-11-21 18:19:58 Re: View with duplicate GROUP BY entries
Previous Message Robert Haas 2017-11-21 18:09:58 Re: [COMMITTERS] pgsql: Add hash partitioning.