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@svana.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.