Обсуждение: pgsql: Cause pg_proc.probin to be declared as text, not bytea.

Log Message:
-----------
Cause pg_proc.probin to be declared as text, not bytea.  Everything was
already treating it as text anyway, to the point that I couldn't find anything
to change except the datatype markings in catalog/*.h.  The only effect that
the bytea declaration had was to cause byteaout() to be invoked when pg_dump
(or another client program) inspected the column value.  Since pg_dump wasn't
expecting that, but just treating what it got as text, the net result is that
dump and reload would mangle any backslashes or non-ASCII characters in the
filename string for a C-language function.  That is a very long-standing bug,
but given the lack of field complaints it doesn't seem worth trying to find
a back-patchable fix.  We'll just make this change to fix it going forward.

This change will also forestall problems after the planned change to let bytea
emit hex output instead of escaped characters.

Modified Files:
--------------
    pgsql/doc/src/sgml:
        catalogs.sgml (r2.204 -> r2.205)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/catalogs.sgml?r1=2.204&r2=2.205)
    pgsql/src/include/catalog:
        catversion.h (r1.536 -> r1.537)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h?r1=1.536&r2=1.537)
        pg_attribute.h (r1.150 -> r1.151)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_attribute.h?r1=1.150&r2=1.151)
        pg_proc.h (r1.548 -> r1.549)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_proc.h?r1=1.548&r2=1.549)

On Tue, Aug 4, 2009 at 5:04 AM, Tom Lane<tgl@postgresql.org> wrote:
> Cause pg_proc.probin to be declared as text, not bytea.

Doesn't this relate to the earlier discussion of whether to re-encode
filenames and paths?

What's going to happen if I have filenames which aren't valid encoded
strings in the server encoding -- say UTF8 filenames but I'm using
latin1 in the server or vice versa. Will my CREATE FUNCTION command
end up storing an invalid encoded string? Or re-encode the filename
and then fail to find the file?

--
greg
http://mit.edu/~gsstark/resume.pdf