Re: [COMMITTERS] pgsql: Cause pg_proc.probin to be declared as text, not bytea.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Cause pg_proc.probin to be declared as text, not bytea.
Date: 2009-08-04 13:46:45
Message-ID: 21889.1249393605@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Tue, Aug 4, 2009 at 5:04 AM, Tom Lane<tgl(at)postgresql(dot)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?

Right at the moment we simply aren't considering any of those cases.
If you'd like to propose and implement a solution, feel free. I think
the last proposal foundered on the fact that it had no idea what
encoding the filesystem was expecting anyway.

I'll point out though that having probin declared bytea would surely
be antithetical to any attempt to treat shlib filenames in an
encoding-aware fashion. Declaring it that way implies that it is
*not* storing a character string that has any particular encoding.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Greg Stark 2009-08-04 14:42:34 Re: [COMMITTERS] pgsql: Cause pg_proc.probin to be declared as text, not bytea.
Previous Message User Maosen 2009-08-04 12:46:12 pgexternaltable - src:

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2009-08-04 13:51:27 Re: async notification patch for dblink
Previous Message Tom Lane 2009-08-04 13:41:13 Re: SE-PostgreSQL Specifications