Tatsuo Ishii <[EMAIL PROTECTED]> 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 like
convert(bytea) returns bytea
or possibly
convert(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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
