Re: select_common_collation callers way too ready to throw error - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: select_common_collation callers way too ready to throw error
Date
Msg-id 1299787542.9423.1.camel@vanquo.pezone.net
Whole thread Raw
In response to select_common_collation callers way too ready to throw error  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: select_common_collation callers way too ready to throw error
List pgsql-hackers
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.




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Next
From: Bruce Momjian
Date:
Subject: Re: configure gaps