pgsql: Throw error for indeterminate collation of an ORDER/GROUP/DISTIN
Throw error for indeterminate collation of an ORDER/GROUP/DISTINCT target.
This restores a parse error that was thrown (though only in the ORDER BY
case) by the original collation patch. I had removed it in my recent
revisions because it was thrown at a place where collations now haven't
been computed yet; but I thought of another way to handle it.
Throwing the error at parse time, rather than leaving it to be done at
runtime, is good because a syntax error pointer is helpful for localizing
the problem. We can reasonably assume that the comparison function for a
collatable datatype will complain if it doesn't have a collation to use.
Now the planner might choose to implement GROUP or DISTINCT via hashing,
in which case no runtime error would actually occur, but it seems better
to throw error consistently rather than let the error depend on what the
planner chooses to do. Another possible objection is that the user might
specify a nondefault sort operator that doesn't care about collation
... but that's surely an uncommon usage, and it wouldn't hurt him to throw
in a COLLATE clause anyway. This change also makes the ORDER BY/GROUP
BY/DISTINCT case more consistent with the UNION/INTERSECT/EXCEPT case,
which was already coded to throw this error even though the same objections
could be raised there.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/37d6d07dda28a5dffcad6ff195ab2c83aaebcc9e
Modified Files
--------------
src/backend/parser/parse_collate.c | 24 ++++++++++++++++++++++
src/test/regress/expected/collate.linux.utf8.out | 5 ++++
src/test/regress/expected/collate.out | 5 ++++
src/test/regress/sql/collate.linux.utf8.sql | 1 +
src/test/regress/sql/collate.sql | 1 +
5 files changed, 36 insertions(+), 0 deletions(-)
On Tue, Mar 22, 2011 at 7:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Throw error for indeterminate collation of an ORDER/GROUP/DISTINCT target.
hmm. In the current arrangement = doesn't depend on collation, right?
So in an ideal world we could use any collation we want to implement
GROUP/DISTINCT/UNION/INTERSECT/EXCEPT. I can see how it would be hard
to generate paths for every possible collation but it would be awfully
nice if we had a way to represent this so we could pick whichever
index we thought would be fastest instead of relying on the user to
select one.
--
greg
Greg Stark <gsstark@mit.edu> writes:
On Tue, Mar 22, 2011 at 7:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Throw error for indeterminate collation of an ORDER/GROUP/DISTINCT target.
hmm. In the current arrangement = doesn't depend on collation, right?
I've been trying to get rid of that assumption where I could.
I think it would probably be interesting if someday we could have
case-insensitive collations, for instance.
regards, tom lane