Re: pg_execute_from_file, patch v10

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_execute_from_file, patch v10
Date: 2010-12-14 02:41:46
Message-ID: AANLkTi=ORNKZidAfJKsh1pGwBJi49EcsBReEA9E60YMj@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 14, 2010 at 10:53, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I'm looking at this patch and I'm confused.  Why do we need this at
> all?  pg_read_binary_file() seems like it might be useful to somebody,
> but I don't see what it has to do with extensions.  And the rest of
> this doesn't appear to provide any new functionality.  The extension
> mechanism hardly needs SQL-callable functions.

Hmm, I've expected that the EXTENSION patch would use the SQL functions
like as SPI_exec("SELECT pg_execute_sql(pg_read_file($1))", ...), but
it actually uses internal functions and nested DirectFunctionCalls.
So, the most important part of this patch is allowing to read any
files in the server file system. The current pg_read_file() allows
to read only files under $PGDATA and pg_log.

However, the interface of current pg_read_file() is mis-designed
to read files in multi-byte encoding because
1. The encoding must be same with the server encoding.
2. Users need to specify correct offset in the file
not to split multi-byte characters.
So, it'd be better to improve pg_read_file() aside from EXTENSION anyway.
I think pg_read_whole_binary_file() is one of the solutions for the issue.

--
Itagaki Takahiro

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-14 02:51:00 Re: pg_execute_from_file, patch v10
Previous Message Tom Lane 2010-12-14 02:23:05 Re: Transaction-scope advisory locks