public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Stuart Campbell <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: [email protected]
Subject: Re: Unexpected modification of check constraint definition
Date: Wed, 07 Jan 2026 17:24:01 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAAZ6SnxaG7zCkmcktjULXRWJM_ZVCdqsdhnyZQWsWCx_uVeisw@mail.gmail.com>
References: <CAAZ6SnzFLQzraWws7_ZKjGtJ+XNK+Hz9DStGbEPzzHKjUXqELQ@mail.gmail.com>
	<[email protected]>
	<CAAZ6SnxaG7zCkmcktjULXRWJM_ZVCdqsdhnyZQWsWCx_uVeisw@mail.gmail.com>

Stuart Campbell <[email protected]> writes:
> On Wed, Jan 7, 2026 at 11:57 PM Laurenz Albe <[email protected]>
> wrote:
>> That implicit cast is made explicit when the parsed binary form of the
>> constraint expression is
>> reverse engineered to a string during "pg_dump".

> Makes sense.

For context, in pg_dump we are quite concerned that the dumped form of
the expression be interpreted the same way when reloaded, so that's
why implicit casts get made explicit.  (The worry is mainly that the
destination server could have a different set of available operators or
casting rules, so it might opt for some different interpretation of
an underspecified expression.)  This isn't a perfect rule, because the
parser may behave subtly differently when faced with different input,
but it's the best we've been able to do.

> That seems reasonable. What mostly seemed unexpected was that the parsed
> expression changed the second time. i.e. original expression -> rewritten
> expression with explicit type casting -> rewritten expression with (even
> more!) explicit type casting.

Yeah, this is actually a pretty complicated case, because the parser
decides that it ought to convert the IN to an "= ANY(ARRAY)"
construct.  That opens up the question of whether to cast at the level
of the individual array elements, or at the level of the array as a
whole.  The heuristics for that get affected by what casts were in the
original input.

			regards, tom lane

view thread (3+ 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]
  Subject: Re: Unexpected modification of check constraint definition
  In-Reply-To: <[email protected]>

* 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