Yes, using "varchar" is definitely part of why it is so odd.
There is no equality operator for "varchar", so you need an (implicit) cast to "text".
Got it. That seems like a possible reason to prefer text over varchar.
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.
I'd say that the change you mention "just happened", but you can never rely on these expressions
being rendered in a fixed way - this can change any time.
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.
But perhaps it is good enoulh if you define the constraint by casting to "text"
early: CHECK (val::text IN ('a','b','c'))
Sounds good, I may try that. Thanks!
> This communication and any attachments may contain confidential information and are intended to be
> viewed only by the intended recipients.
Got it, I won't forward your mail... err...
Heh, yes... sorry about that. I can't control how that message is included from this email address. Rest assured, you and everyone else here are the intended recipients :-)
Regards,
Stuart
This communication and any attachments may contain confidential information and are intended to be viewed only by the intended recipients. If you have received this message in error, please notify the sender immediately by replying to the original message and then delete all copies of the email from your systems.
