Re: the case for machine-readable error fields

On Wed, Aug 05, 2009 at 01:29:13PM +0200, Pavel Stehule wrote:
> > What are people doing with parsing error messages for "column names for
> > datatype mismatches"? I can't imagine any of my code being able to do
> > anything sensible in such a case. If it's things like people giving
> > dates to the database in an incorrect format then that's what they get
> > for not doing input validation isn't it?
>
> When you have a full set of constraint, then you don't need to
> validate input. Just you will execute statement.

OK, then we mean different things when we say "validate input". I was
just meaning "simple" things like checking dates are well formed and
that you're not passing things like 'sam's test' into the database
(i.e. that you're actually escaping things correctly). Constraints
are different from input validation as they rely on state that the
database's client by definition doesn't have (otherwise it would be able
to do the constraint checking just as well as the database).

> When execution is
> correct, then all is ok, when not, then you have to recheck message,
> err code, ... and you have to verify, so some exception is expected or
> not. This is programming based on exceptions. Some better structured
> information helps. And what's more - this should be in conformity with
> ANSI SQL.

Humans can interpret the current error messages just fine, I don't
believe that code could do with "better structured information".

It would be possible to have the *Params libpq functions (not sure where
this lives in the underlying protocols) give back errors when its inputs
can't be parsed, but that seems like a different problem.

Describing where problems are in a machine readable format from
arbitrary code seems very fragile.

--
Sam http://samason.me.uk/