Re: Practical error logging for very large COPY

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Practical error logging for very large COPY
Date: 2005-11-22 17:56:48
Message-ID: 20051122175648.GH12548@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 22, 2005 at 12:16:00PM -0500, Tom Lane wrote:
> I think the distinction you are proposing between constraint errors
> and datatype errors is entirely artificial. Who's to say what is a
> constraint error and what is a datatype error, especially when you
> start thinking about cases like varchar length constraints or
> domain-type constraints? If we create a mechanism that behaves
> differently depending on whether the error is detected before or after
> we try to form a tuple containing the data, we're going to have
> something that is exceedingly awkward to use, because the behavior will
> be nearly arbitrary from the user's viewpoint.

By that reasoning, to be consistant, we should never pass any data at
all, which seems even more useless. This is however what other
databases do, but I think we can do better.

I don't think the distinction is really that arbitrary. If the data can
be represented as a tuple in the correct datatypes, you're fine. Domain
types are tricky, but to be consistant they should get the tuple data
either.

My main reasoning is that while you can write a 3 line Perl script to
verify the format of all your integers, you can't write a script in any
language to check for foreign key constraints or duplicate key errors.
So those are the important actions. If it comes down to making datatype
errors untrappable then I think I can live with that.

MY thinking was that if it happening in the executor or parser, tough.
That we only handle errors happing at the final insert/update/delete.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume Lelarge 2005-11-22 18:02:35 Re: server closed connection on a select query
Previous Message Tom Lane 2005-11-22 17:55:04 Re: server closed connection on a select query