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.
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. |