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
