Re: [HACKERS] select_common_collation callers way too ready to throw error
On ons, 2011-03-09 at 18:07 -0500, Tom Lane wrote: The first of these errors is OK, but surely the second is not, because || doesn't give a fig about collations. I think instead of this: /* XXX: If we knew which functions required collation information, * we could selectively set the last argument to true here. */ funccollid = select_common_collation(pstate, fargs, false); we need: /* * If we knew which functions required collation information, * we could selectively set the last argument to false here, * allowing the error to be reported at parse time not runtime. */ funccollid = select_common_collation(pstate, fargs, true); Now the downside of that is that a runtime failure won't give you an parse error pointer to indicate which function is having trouble ... but having an error pointer for an error that shouldn't be thrown in the first place is small consolation. Sounds reasonable. Btw., the ultimate plan here was that functions or operators that would care about collation would be marked as such in pg_proc. That plan basically just ran out of time, but if you think it'd be useful, maybe we could reactivate it quickly. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] select_common_collation callers way too ready to throw error
Peter Eisentraut pete...@gmx.net writes: On ons, 2011-03-09 at 18:07 -0500, Tom Lane wrote: Now the downside of that is that a runtime failure won't give you an parse error pointer to indicate which function is having trouble ... but having an error pointer for an error that shouldn't be thrown in the first place is small consolation. Sounds reasonable. Btw., the ultimate plan here was that functions or operators that would care about collation would be marked as such in pg_proc. That plan basically just ran out of time, but if you think it'd be useful, maybe we could reactivate it quickly. I think it's worth doing at some point, but not right now. By the time you get done adding support for the flag to CREATE FUNCTION, pg_dump, etc, it's not a small task. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] select_common_collation callers way too ready to throw error
db1=# create table t1 (f1 text collate aa_DJ.utf8, f2 text collate an_ES.utf8 ); CREATE TABLE db1=# select f1 f2 from t1; ERROR: collation mismatch between implicit collations aa_DJ.utf8 and an_ES.utf8 LINE 1: select f1 f2 from t1; ^ HINT: You can override the collation by applying the COLLATE clause to one or both expressions. db1=# select f1 || f2 from t1; ERROR: collation mismatch between implicit collations aa_DJ.utf8 and an_ES.utf8 LINE 1: select f1 || f2 from t1; ^ HINT: You can override the collation by applying the COLLATE clause to one or both expressions. The first of these errors is OK, but surely the second is not, because || doesn't give a fig about collations. I think instead of this: /* XXX: If we knew which functions required collation information, * we could selectively set the last argument to true here. */ funccollid = select_common_collation(pstate, fargs, false); we need: /* * If we knew which functions required collation information, * we could selectively set the last argument to false here, * allowing the error to be reported at parse time not runtime. */ funccollid = select_common_collation(pstate, fargs, true); Now the downside of that is that a runtime failure won't give you an parse error pointer to indicate which function is having trouble ... but having an error pointer for an error that shouldn't be thrown in the first place is small consolation. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
