| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> | 
| Cc: | pgsql-hackers(at)postgreSQL(dot)org | 
| Subject: | Re: select_common_collation callers way too ready to throw error | 
| Date: | 2011-03-10 20:14:51 | 
| Message-ID: | 21527.1299788091@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Peter Eisentraut <peter_e(at)gmx(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2011-03-10 20:22:47 | Re: Theory of operation of collation patch | 
| Previous Message | Bruce Momjian | 2011-03-10 20:14:03 | Re: configure gaps |