Re: select_common_collation callers way too ready to throw error

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: select_common_collation callers way too ready to throw error
Date: 2011-03-10 20:05:42
Message-ID: 1299787542.9423.1.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-03-10 20:14:03 Re: configure gaps
Previous Message Robert Haas 2011-03-10 20:04:57 Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.