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
Message-ID: 87zircga6w.fsf@credativ.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

regards
Andreas

In response to

Responses

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