Re: A proper fix for the conversion-function problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: A proper fix for the conversion-function problem
Date
Msg-id 13765.1115173745@sss.pgh.pa.us
Whole thread Raw
In response to Re: A proper fix for the conversion-function problem  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List 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 by date:

Previous
From: "Andrew Dunstan"
Date:
Subject: Re: inclusions WAS: Increased company involvement
Next
From: Mischa Sandberg
Date:
Subject: Re: [PERFORM] Bad n_distinct estimation; hacks suggested?