Re: pg_execute_from_file, patch v10
От | Robert Haas |
---|---|
Тема | Re: pg_execute_from_file, patch v10 |
Дата | |
Msg-id | AANLkTinSp_B9KoabvqA6fYAchi+9j3K8pGPKuZ9pf1wJ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_execute_from_file, patch v10 (Itagaki Takahiro <itagaki.takahiro@gmail.com>) |
Ответы |
Re: pg_execute_from_file, patch v10
|
Список | pgsql-hackers |
On Tue, Dec 14, 2010 at 9:25 PM, Itagaki Takahiro <itagaki.takahiro@gmail.com> wrote: > On Wed, Dec 15, 2010 at 03:42, Robert Haas <robertmhaas@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
В списке pgsql-hackers по дате отправления: