| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Junwang Zhao <zhjwpku(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Sutou Kouhei <kou(at)clear-code(dot)com>, nathandbossart(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Make COPY format extendable: Extract COPY TO format implementations |
| Date: | 2023-12-08 07:02:55 |
| Message-ID: | ZXK_n_pFadvT04QS@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Dec 08, 2023 at 03:42:06PM +0900, Masahiko Sawada wrote:
> So a custom COPY extension would not be able to define SQL functions
> just like arrow(internal) for example. We might need to define a rule
> like the function returning copy_in/out_handler must be defined as
> <method name>_to(internal) and <method_name>_from(internal).
Yeah, I was wondering if there was a trick to avoid the input internal
argument conflict, but cannot recall something elegant on the top of
my mind. Anyway, I'd be OK with any approach as long as it plays
nicely with the query integration, and that's FORMAT's DefElem with
its string value to do the function lookups.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alena Rybakina | 2023-12-08 07:09:07 | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) |
| Previous Message | Amit Langote | 2023-12-08 06:59:27 | Re: remaining sql/json patches |