public inbox for [email protected]  

help / color / mirror / Atom feed

From: Valerio Battaglia <[email protected]>
To: Tom Lane <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: How to get column, table or parameter name reporting when violating DOMAIN type constraint
Date: Mon, 27 Mar 2023 02:37:59 +0200
Message-ID: <CACxJNS=sXe14q3o1_VXpU+fkuKcc5r09xqVLva68kY30hvf9qw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CACxJNSkpT8vC0jnsfObZDargLA1vCiP-VKF2ji9y58VaAOSpVA@mail.gmail.com>
	<CAKFQuwYJtF-5Uvqo6ahKkeEAxOKta_yVb3n3at5Y=mvSgC0FrA@mail.gmail.com>
	<[email protected]>
	<CAKFQuwa00CR2HPxmngsGqx0mGOc4j215gZ4j_v32OYO_gfpQYg@mail.gmail.com>
	<[email protected]>

Thanks for the answer and explanation. My reasoning behind the use of
domains, particularly in function calls, is to have a useful approach for
validating input before it enters a function. By doing so, it eliminates
the need to manually verify input for public / exposed functions, and would
effectively make domains provide an efficient way to encapsulate and
enforce business rules.

Considering the aforementioned example, having a message reporting with the
position name would make the consumer life much easier, program or human
alike

SELECT my_function(100, -100);
-- ERROR: value "second_parameter" for domain my_domain violates check
constraint "value_min"

SELECT (-1)::my_domain;
-- ERROR: value "unnamed" for domain my_domain violates check
constraint "value_min"


Valerio

On Sun, 26 Mar 2023 at 18:00, Tom Lane <[email protected]> wrote:

> "David G. Johnston" <[email protected]> writes:
> > On Sunday, March 26, 2023, Tom Lane <[email protected]> wrote:
> >> More to the point, you have the wrong mental model: a domain constraint
> >> violation might not be associated with a table column at all.
>
> > I disagree that the mental model is wrong.
>
> The OP is asking for action-at-a-distance.  There are probably cases
> where the distance is short enough that we could associate the runtime
> error with a particular insertion target column, but I don't think it
> could possibly be made to work for every sort of insert/select query.
> In any case, the possibility of a hypothetical future feature (which
> nobody is actively working on AFAIK) doesn't seem like a very useful
> answer here.
>
> > There are existing threads that I may hunt later.  IIRC, you (Tom) even
> > suggested a possible way forward on this last time it came up.
>
> I recall proposing that we try to produce syntax-error-like error
> cursors for runtime errors, but it's not apparent to me that that'd
> be tremendously applicable to the OP's problem.  The output would
> look something like
>
> ERROR: value for domain my_domain violates check constraint "value_min"
> LINE 1: SELECT my_function(100, -100);
>                                 ^
>
> which might be helpful for a human, but probably not very much so
> for a program.  (BTW, this illustrates another issue: I'm pretty
> sure that in the given case, the error is thrown while evaluating
> my_function's arguments, long before we get within hailing distance
> of any INSERT at all.)
>
>                         regards, tom lane
>

view thread (6+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: How to get column, table or parameter name reporting when violating DOMAIN type constraint
  In-Reply-To: <CACxJNS=sXe14q3o1_VXpU+fkuKcc5r09xqVLva68kY30hvf9qw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox