Re: Please implement a catch-all error handler per row, for COPY - Mailing list pgsql-general

From me nefcanto
Subject Re: Please implement a catch-all error handler per row, for COPY
Date
Msg-id CAEHBEOBAYsELbjC7KvifHk00jNVJvCRpZkHDML9ebsP48g4w+A@mail.gmail.com
Whole thread Raw
In response to Re: Please implement a catch-all error handler per row, for COPY  (Greg Sabino Mullane <htamfids@gmail.com>)
Responses Re: Please implement a catch-all error handler per row, for COPY
Re: Please implement a catch-all error handler per row, for COPY
Re: Please implement a catch-all error handler per row, for COPY
Re: Please implement a catch-all error handler per row, for COPY
List pgsql-general
Thank you all for responding. With respect, I don't understand why COPY gets related to ETL. All of the requirements I mentioned above have nothing to do with ETL. We have a table of categories. A hierarchical table. This is a multitenant app. Hundreds of thousands of records are in it. We want to calculate the hierarchical properties (nested set models, node depth, determining leaves, materialized paths, etc.) and then update the entire table. What does this have to do with ETL? Or as I said we create millions of records for products, attributes of products, and pricing and media of products to load test our system. Again, what does that have to do with ETL?

The point is, that there is already an `on_error ignore` clause there. This means that somewhere there is a try/catch per row. If I'm wrong, please let me know. But when the `on_error ignore` catches problem x for each row, then it can catch all problems for each row without any performance problem.

Let me give you an example in C#:

try 
{
}
catch (SomeException ex)
{
}

becomes:

try
{
}
catch (Exception ex)
{
    if (ex is SomeException)
    {
    }
}

The last catch clause catches everything. How does it affect performance? Running a simple if for hundreds of millions of iterations is literally nothing in time complexity.

As I have specified in the bug thread, from 11 RDBMSs, 7 support this. Thus it's not an uncommon weird request.

Regards
Saeed

On Sat, Mar 1, 2025 at 8:45 PM Greg Sabino Mullane <htamfids@gmail.com> wrote:
FYI the -bugs thread in question:


seems to imply the primary blocker was a unique constraint.

Cheers,
Greg

--
Enterprise Postgres Software Products & Tech Support

pgsql-general by date:

Previous
From: Krishnakant Mane
Date:
Subject: Re: create_immv issue on aws Ubuntu even after create extention
Next
From: Christophe Pettus
Date:
Subject: Re: Please implement a catch-all error handler per row, for COPY