> You mean that the default generated error messages contain some more
> information I presume, like the table name and the constraint name ?
Even better, the information is *structured* afaik.
> I think I noticed that already, and since I had time since yesterday
> evening, I thought things over
On Sun, 30 May 2004 22:08:10 +0200
Karsten Hilbert <[EMAIL PROTECTED]> wrote:
> > This then, removes the first part of my explanation, and dumps me
> > completely in the second part, which is where the biggest problems
> > reside.
> AFAICT 7.4 does much better error handling (no, you can't
> easil
> This then, removes the first part of my explanation, and dumps me
> completely in the second part, which is where the biggest problems
> reside.
AFAICT 7.4 does much better error handling (no, you can't
easily control error handling inside a transaction, though). It
reports errors in a way that c
On Sun, 30 May 2004 20:04:50 +0200
Karsten Hilbert <[EMAIL PROTECTED]> wrote:
> > a) The basic contents of the internal data dictionary can be used to
> > check incoming fields from on their length and permitted contents.
> >
> > b) With a little extra work, I should be able to define a table
> >
> a) The basic contents of the internal data dictionary can be used to
> check incoming fields from on their length and permitted contents.
>
> b) With a little extra work, I should be able to define a table which
> can be used to check field contents against field masks.
You can use column check
I am currently designing an application which should be accessible from
different interfaces. For this I like to be using stored procedures to
process the contents of form submissions and dialog screens.
After studying the PG database, it seems to me that I can fulfill the
following requirements.
