On Mon, Aug 3, 2009 at 10:03 PM, Tom Lane<t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
