On Tue, Dec 14, 2010 at 9:25 PM, Itagaki Takahiro <itagaki.takah...@gmail.com> wrote: > On Wed, Dec 15, 2010 at 03:42, Robert Haas <robertmh...@gmail.com> wrote: >>>> I think #2 might be a nice thing to have, but I'm not sure what it has >>>> to do with extensions. >>> >>> Agreed. There might be some use for #4 in connection with extensions, >>> but I don't see that #2 is related. >>> >>> BTW, it appears to me that pg_read_file expects server encoding not >>> client encoding. Minor detail only, but let's be clear what it is >>> we're talking about. > > EXTENSION will use #2 with convert_from() for $4 like this: > > Datum sql = replace( > convert_from(pg_read_binary_file($path), $encoding), > '@extschema@', $schema); > SPI_exec(TextDatumGetCString(sql)); > > I think it is a more flexible solution than adding 'encoding' > parameter to pg_read_file().
It seems like pg_read_binary_file() is good to have regardless of whatever else we decide to do here. Should we pull that part out and commit it separately? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
