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