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: | Raw Message | Whole Thread | 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 |