Thread: 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.
regards, tom lane
> 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 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
> 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 > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of John Hansen > Sent: Wednesday, May 04, 2005 1:22 PM > To: Tom Lane; Tatsuo Ishii > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] A proper fix for the > conversion-function problem > > > Are there any encodings we care about that require embedded zero > bytes? > > UTF-8 does! > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > >
"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