Re: View with duplicate GROUP BY entries - Mailing list pgsql-hackers

From Robert Haas
Subject Re: View with duplicate GROUP BY entries
Date
Msg-id CA+TgmobDf4i5mBhStwehmxmB6d8OACWXqS+LbHbkPxCkQ3vEBw@mail.gmail.com
Whole thread Raw
In response to Re: View with duplicate GROUP BY entries  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Nov 21, 2017 at 1:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Nov 21, 2017 at 12:05 PM, Tom Lane <tgl@sss.pgh.pa.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.

Oh, woops.  Sorry.

> 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.

That's not an unreasonable goal, but I'm not sure how much effort I'd
personally be willing to expend on it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: View with duplicate GROUP BY entries
Next
From: Tom Lane
Date:
Subject: Re: feature request: consume asynchronous notification via a function