Re: View with duplicate GROUP BY entries

[Tom Lane]

Robert Haas  writes:
> On Tue, Nov 21, 2017 at 12:05 PM, Tom Lane  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

Re: View with duplicate GROUP BY entries

[Robert Haas]

On Tue, Nov 21, 2017 at 12:05 PM, Tom Lane  wrote:
> Ashutosh Bapat  writes:
>> While reviewing patch for similar problem in postgres_fdw [1], I
>> noticed that we don't use positional notation while creating the view.
>> This might introduced anomalies when GROUP BY entries are
>> non-immutable.
>
> 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.

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

Re: View with duplicate GROUP BY entries

[Tom Lane]

Ashutosh Bapat  writes:
> While reviewing patch for similar problem in postgres_fdw [1], I
> noticed that we don't use positional notation while creating the view.
> This might introduced anomalies when GROUP BY entries are
> non-immutable.

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.  We might have to extend the
parsetree representation so that we can tell whether positional notation
was used to begin with.

regards, tom lane