pg_proc.probin is currently declared as being type bytea. Perhaps that
had some real utility once upon a time, but no currently defined
procedural language stores binary data there. In fact, the only
thing that gets stored there is the shared-library file name for
C functions. To make things even more fun, none of the code touching
probin is doing anything to honor the special escaping conventions for
bytea. This was pretty broken already, and might perhaps explain some
of the weirder error reports we've gotten. It is now obvious to me
that no shlib file name containing non-ASCII characters will correctly
survive a dump/reload, in any existing PG release. Backslashes
accidentally fail to fail, at least for some values of
standard_conforming_strings.
However, with the hex bytea output patch in place, it's *completely*
broken. I offer the following pg_dump output:
CREATE FUNCTION interpt_pp(path, path) RETURNS point
LANGUAGE c
AS
'\\x2f686f6d652f706f7374677265732f706773716c2f7372632f746573742f726567726573732f726567726573732e736c',
'interpt_pp';
which should of course have looked like this:
CREATE FUNCTION interpt_pp(path, path) RETURNS point
LANGUAGE c
AS '/home/postgres/testversion/src/test/regress/regress.sl', 'interpt_pp';
I think that the least painful solution might be to change
pg_proc.probin to be declared as text. Otherwise we're going to need
version-specific klugery in pg_dump and who knows where else.
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
