MIME-Version: 1.0
References: <CAEHBEOCqqkSitU5gx=8aHD3ZeLtRy-1eC=Xs=xB-thFNR9JpYA@mail.gmail.com>
 <2961422.1740846012@sss.pgh.pa.us>
In-Reply-To: <2961422.1740846012@sss.pgh.pa.us>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Sat, 1 Mar 2025 09:35:54 -0700
Message-ID: <CAKFQuwbRCWP2DMHyW1LABuWAjDFVGE4mPJNfXOeTqzMpeBQ_Hw@mail.gmail.com>
Subject: Re: Please implement a catch-all error handler per row, for COPY
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: me nefcanto <sn.1361@gmail.com>, pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000a4a2b3062f4a861b"
Archived-At: <https://www.postgresql.org/message-id/CAKFQuwbRCWP2DMHyW1LABuWAjDFVGE4mPJNfXOeTqzMpeBQ_Hw%40mail.gmail.com>
Precedence: bulk

--000000000000a4a2b3062f4a861b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 1, 2025 at 9:20=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> me nefcanto <sn.1361@gmail.com> writes:
> > Can you please provide a row-level catch-all handler for the copy
> command?
>
> Very unlikely to happen.  COPY is not intended as a general purpose
> ETL mechanism, and we don't want to load it down with features that
> would create substantial performance penalties.  Which that would.
>

Maybe it isn't a general purpose ETL tool but there is no reasonable way to
do some things unless COPY can be put into a mode that doesn't have the
same performance requirements it needs to serve as our dump/restore tool of
choice.

I have to imagine such a mode, if not enabled, would have little to no
impact on how COPY behaves compared to today.  It's kinda like VACUUM FULL
existing doesn't impact how VACUUM behaves.  Seems more desirable than
inventing a whole new SQL Command to do this and copy-paste all of the COPY
code since it does mostly the same thing.

In short, it's probably worth giving it a try if someone wants to.
Rejecting it without seeing the proposal seems premature.

Now, it's probably challenging enough that if the person requesting the
feature isn't driving its development the odds of it getting worked on is
fairly low.

David J.

--000000000000a4a2b3062f4a861b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif"><span style=3D"font-family:Arial,Helve=
tica,sans-serif">On Sat, Mar 1, 2025 at 9:20=E2=80=AFAM Tom Lane &lt;<a hre=
f=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; wrote:</span></div=
></div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">me nefcanto &lt;<a href=3D"mailto:sn.1361@=
gmail.com" target=3D"_blank">sn.1361@gmail.com</a>&gt; writes:<br>
&gt; Can you please provide a row-level catch-all handler for the copy comm=
and?<br>
<br>
Very unlikely to happen.=C2=A0 COPY is not intended as a general purpose<br=
>
ETL mechanism, and we don&#39;t want to load it down with features that<br>
would create substantial performance penalties.=C2=A0 Which that would.<br>=
</blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif">Maybe it isn&#39;t a general purpose ET=
L tool but there is no reasonable way to do some things unless COPY can be =
put into a mode that doesn&#39;t have the same performance requirements it =
needs to serve as our dump/restore tool of choice.</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">I h=
ave to imagine such a mode, if not enabled, would have little to no impact =
on how COPY behaves compared to today.=C2=A0 It&#39;s kinda like VACUUM FUL=
L existing doesn&#39;t impact how VACUUM behaves.=C2=A0 Seems more desirabl=
e than inventing a whole new SQL Command to do this and copy-paste all of t=
he COPY code since it does mostly the same thing.</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">In s=
hort, it&#39;s probably worth giving it a try if someone wants to.=C2=A0 Re=
jecting it without seeing the proposal seems premature.</div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif"><br></div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
">Now, it&#39;s probably challenging enough that if the person requesting t=
he feature isn&#39;t driving its development the odds of it getting worked =
on is fairly low.</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif">David J.</div></div></div></div>

--000000000000a4a2b3062f4a861b--