Re: Proposal: CREATE CONVERSION
От | Tom Lane |
---|---|
Тема | Re: Proposal: CREATE CONVERSION |
Дата | |
Msg-id | 11522.1025884238@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal: CREATE CONVERSION (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: Proposal: CREATE CONVERSION
|
Список | pgsql-hackers |
Tatsuo Ishii <t-ishii@sra.co.jp> writes: >> Doesn't a conversion currently require several support functions? >> How much overhead will you be adding to funnel them all through >> one function? > No, only one function is sufficient. What else do you think of? I see two different functions linked to from each pg_wchar_table entry... although perhaps those are associated with encodings not with conversions. >> Basically I'd like to see a spec for the API of the conversion >> function... > That would be very simple (the previous example I gave was unnecessary > complex). The function signature would look like: > conversion_funcion(TEXT) RETURNS TEXT > It receives source text and converts it then returns it. That's all. IIRC the existing conversion functions deal in C string pointers and lengths. I'm a little worried about the extra overhead implicit in converting to a TEXT object and back again; that probably means at least two more palloc and memcpy operations. I think you'd be better off sticking to a C-level API, because I really don't believe that anyone is going to code conversion functions in (say) plpgsql. regards, tom lane
В списке pgsql-hackers по дате отправления: