Re: Coping with 'C' vs 'newC' function language names
| От | Jan Wieck | 
|---|---|
| Тема | Re: Coping with 'C' vs 'newC' function language names | 
| Дата | |
| Msg-id | 200011151109.GAA01605@jupiter.jw.home обсуждение исходный текст | 
| Ответ на | Re: Coping with 'C' vs 'newC' function language names (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Ответы | Re: Coping with 'C' vs 'newC' function language names Re: Coping with 'C' vs 'newC' function language names | 
| Список | pgsql-hackers | 
Tom Lane wrote: > > More to the point, I think we have to assume old-style interface if we > see ... LANGUAGE 'C' with no other decoration, because any other > assumption is guaranteed to break all existing user-defined functions. Just successfully loading an old-style C function doesn't guarantee that it works anyway. I pointed out before thatthe changes due to TOAST require each function that takes arguments of varlen types to expect toasted values. Worst case a dump might reload and anything works fine, but a month later the first toasted value appears and the old-style C function corrupts the data without a single warning. We need to WARN, WARN and explicitly WARN users of selfmade C functions about this in any possible place! Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: