| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Nicolas Paris <niparisco(at)gmail(dot)com>, pgsql-general General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: New Copy Formats - avro/orc/parquet |
| Date: | 2018-02-12 14:09:18 |
| Message-ID: | 30861.1518444558@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> +1. And bonus points if an API can also be defined so such an extension
> parsing also becomes useful to file_fdw automatically (or at least
> optionally).
Hm, well, file_fdw already goes through COPY FROM, so it seems like it'd
almost just work. "Almost" because there'd need to be a way for it to
support the appropriate options. So this means that whatever the
mechanism is for extension-specific options, it has to be introspectable
enough for file_fdw.c to understand what to expose as FDW options.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Luis Carril | 2018-02-12 15:07:40 | Trying to the behavior of a parallel query with with a change in the transaction isolation mode |
| Previous Message | Magnus Hagander | 2018-02-12 13:55:08 | Re: New Copy Formats - avro/orc/parquet |