Re: ORDER/GROUP BY expression not found in targetlist

From: Andreas Seltenreich <seltenreich(at)gmx(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ORDER/GROUP BY expression not found in targetlist
Date: 2016-05-26 14:34:15
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Tom Lane writes:

> Andreas Seltenreich <seltenreich(at)gmx(dot)de> writes:
>> Peter Geoghegan writes:
>>> It's surprising that SQL Smith didn't catch something with such simple
>>> steps to reproduce.
>> I removed distinct relatively early because it causes a large part of
>> queries to fail due to it not finding an equality operator it likes. It
>> seems to be more picky about the equality operator than, say, joins.
>> I'm sure it has a good reason to do so?
> It's looking for an operator that is known to be semantically equality,
> by virtue of being the equality member of a btree or hash opclass.
> Type path has no such opclass unfortunately.

As do lots of data types in the regression db while still having an
operator providing semantic equivalence. I was hoping for someone to
question that status quo. Naively I'd say an equivalence flag is
missing in the catalog that is independent of opclasses.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-05-26 14:53:47 Re: Parallel pg_dump's error reporting doesn't work worth squat
Previous Message Nikolay Shaplov 2016-05-26 14:31:08 Re: [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet