Re: A proper fix for the conversion-function problem

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: A proper fix for the conversion-function problem
Дата
Msg-id 13765.1115173745@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: A proper fix for the conversion-function problem  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Список pgsql-hackers
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> Going forward, though, I really think we need to revisit the API
>> for conversion functions.  It seems a bit silly to have the
>> infrastructure to let ordinary users create conversions if they
>> can't create the functions needed to support them.

> Why? Since the functions need to be written in C language, ordinary
> users cannot make them anyway. Same thing can be said to CREATE TYPE.

Isn't that a circular argument?  If the API were not deliberately
designed to make it C-only, you could usefully code conversions in
string-hacking-friendly languages like Perl.

I'd really like to simplify the conversion function signature to
something likeconvert(bytea) returns bytea
or possiblyconvert(cstring) returns cstring
depending on whether you think that it's important to be able to pass
zero bytes transparently.  (The current encoding infrastructure seems
pretty confused about that point --- there are null-terminated strings
in some places and counts in others.  Are there any encodings we care
about that require embedded zero bytes?)
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Andrew Dunstan"
Дата:
Сообщение: Re: inclusions WAS: Increased company involvement
Следующее
От: Mischa Sandberg
Дата:
Сообщение: Re: [PERFORM] Bad n_distinct estimation; hacks suggested?