On 01/15/2011 07:41 PM, Andrew Dunstan wrote:
On 01/15/2011 12:29 PM, Andrew Dunstan wrote:
I've been waiting for the latest FDW patches as patiently as I can,
and I've been reviewing them this morning, in particular the file_fdw
patch and how it interacts with the newly exposed COPY API.
On 01/15/2011 12:29 PM, Andrew Dunstan wrote:
I've been waiting for the latest FDW patches as patiently as I can,
and I've been reviewing them this morning, in particular the file_fdw
patch and how it interacts with the newly exposed COPY API. Overall it
seems to be a whole lot cleaner, and
Tom Lane writes:
> Why is this a good thing? It seems like it would accomplish little
> except to defeat the SQL type system entirely.
It simply allows to have the classical ETL problem solved directly in
the database server, in SQL. That's huge.
Regards,
--
Dimitri Fontaine
http://2ndQuadran
On 01/15/2011 01:24 PM, Itagaki Takahiro wrote:
On Sun, Jan 16, 2011 at 02:29, Andrew Dunstan wrote:
"textarray". This option would require that the foreign table have exactly
one field, of type text[], and would compose all the field strings read from
the file for each record into the array
On Sun, Jan 16, 2011 at 02:29, Andrew Dunstan wrote:
> "textarray". This option would require that the foreign table have exactly
> one field, of type text[], and would compose all the field strings read from
> the file for each record into the array (however many there are).
>
> CREATE FOREIGN
On 01/15/2011 12:44 PM, Tom Lane wrote:
Andrew Dunstan writes:
... So now I'd like to add a
new option to it: "textarray". This option would require that the
foreign table have exactly one field, of type text[], and would compose
all the field strings read from the file for each record into t
Andrew Dunstan writes:
> ... So now I'd like to add a
> new option to it: "textarray". This option would require that the
> foreign table have exactly one field, of type text[], and would compose
> all the field strings read from the file for each record into the array
> (however many there ar
I've been waiting for the latest FDW patches as patiently as I can, and
I've been reviewing them this morning, in particular the file_fdw patch
and how it interacts with the newly exposed COPY API. Overall it seems
to be a whole lot cleaner, and the wholesale duplication of the copy
code is g
