A proper fix for the conversion-function problem

I tried disabling public EXECUTE access on the built-in conversion
functions, as we recommended yesterday, and found that it has one
small problem: the conversion regression test fails. The test is
expecting that unprivileged users can create conversions, but since
CREATE CONVERSION requires you to have execute permissions on the
specified function, they can't if we do this.

This leaves me thinking that the best fix for the back branches
is the one Andrew@supernews originally suggested: modify the
signature for conversion functions to use INTERNAL instead of CSTRING.
I haven't actually experimented with that yet, but will shortly.

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.
--
Tatsuo Ishii

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 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

Are there any encodings we care about that require embedded zero

bytes?

UTF-8 does!

On 2005-05-04, "John Hansen" <john@geeknet.com.au> wrote:

Are there any encodings we care about that require embedded zero
bytes?

UTF-8 does!

nonsense

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

"John Hansen" <john@geeknet.com.au> writes:

Are there any encodings we care about that require embedded zero

bytes?

UTF-8 does!

Surely not. Were you thinking of UTF-16 or UCS-2 or whatever it's
called?

regards, tom lane

Errm.. UTF-16/32

"John Hansen" <john@geeknet.com.au> writes:

Errm.. UTF-16/32

Ah, I thought that was what you meant.

Right now we have a *ton* of problems with supporting encodings that
need embedded zero bytes, because there are APIs all over the place
that use zero-terminated strings. I don't foresee that it will ever
be worth the trouble to make such encodings work natively inside the
backend. It might possibly be worth the trouble to allow 'em as client
encodings ... but that would require fixing not just the encoding
converters, but the FE/BE protocol, libpq, psql, pg_dump, and who knows
what other client-side software.

If we're willing to make a commitment to go down that long hard road,
it'd make sense to define the encoding conversion API to support strings
with embedded nulls. Personally I'm agin it --- I think that the needed
development effort would be better spent elsewhere. But my personal
needs don't stretch further than 7-bit ASCII so maybe I'm not the best
guy to make such decisions.

regards, tom lane