2009/8/4 Tom Lane <tgl@sss.pgh.pa.us>:
> 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?
>
-1
correct solution is moving the path to prosrc col or create new colum
"externalproc". I thing so probin should be useful for plpgsql -
sometime we should to store parser result from plpgsql compilation
stage in this column. So my option is don't change native sense of
this column. If we actually have not using, the we should to drop it,
not create some breaks in future.
Pavel Stehule
> 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
>
