| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> | 
| Cc: | Nicolas Paris <niparisco(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org | 
| Subject: | Re: New Copy Formats - avro/orc/parquet | 
| Date: | 2018-02-11 22:48:13 | 
| Message-ID: | 18464.1518389293@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
Andres Freund <andres(at)anarazel(dot)de> writes:
> So, I think making COPY extensible would be quite beneficial. I'm
> however quite doubtful that we want to add core code to handle all of
> the above. I think we should make the COPY input/output formatting
> extensible by extensions.
+1.  I can't see carrying code for these formats in-core, but I've
no objection to making it possible for someone else to maintain them.
> I imagine we'd have callbacks for
> - start copy in / out
> - output row, with a an array of values/nulls
> - parse row, with a input buffer as argument, returning values / nulls arrays
> - finish copy in / out
Also something to allow absorbing format-specific options, if the
precedent of CSV is anything to go by.  (Any such patch should manage
to turn COPY-CSV into an extension, at least so far as copy.c is
concerned, even if we don't package it as one.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-02-11 22:53:30 | Re: New Copy Formats - avro/orc/parquet | 
| Previous Message | Nicolas Paris | 2018-02-11 22:02:36 | Re: New Copy Formats - avro/orc/parquet |