On Mon, Aug 3, 2009 at 10:03 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> 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?
Will that require a special hack in pg_migrator?
...Robert
