From: | Fabien Coelho <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add partial :-variable expansion to psql \copy |
Date: | 2025-04-05 20:14:39 |
Message-ID: | 279fa33f-fc66-431f-88c9-f0930dad4930@cri.ensmp.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Tom and Corey,
> [...] Anyway, my feeling about it is that \copy parsing is a huge hack
> right now, and I'd rather see it become less of a hack, that is
> more like other psql commands, instead of getting even hackier.
After giving it some thoughts, I concluded that trying to salvage \copy
is not the
way to go and I have followed Corey's suggestion to extend the standard
SQL COPY
handling by providing an alternate input stream with "\gi file" or "\gi
cmd|".
This has lead to significant restructuring so as to simplify \copy
handling to use
the \g and \gi existing infrastructure. I've moved checked performed
only for \copy
so that they are now also done with \g, and error messages are more
systematically
shown. The pipe char used to mark a command instead of a file is
switched to a
boolean, which is more consistent with other places and how it can be
managed with
"\gi command|" as the pipe char is at the end instead of the start. The
patch also
includes tests and some doc.
If this is accepted, ISTM that \copy could be retired and even removed at a
later stage, which would solve elegantly its debatable implementation.
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
psql-copy-var-2.patch | text/x-patch | 26.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2025-04-05 20:16:56 | Re: Parallel heap vacuum |
Previous Message | Tom Lane | 2025-04-05 19:54:18 | Re: [fixed] Trigger test |