public inbox for [email protected]  

help / color / mirror / Atom feed

Re: Unexpected modification of check constraint definition
2+ messages / 2 participants
[nested] [flat]

* Re: Unexpected modification of check constraint definition
@ 2026-01-07 15:24 Adrian Klaver <[email protected]>
  2026-01-07 21:59 ` Re: Unexpected modification of check constraint definition Stuart Campbell <[email protected]>
  0 siblings, 1 reply; 2+ messages in thread

From: Adrian Klaver @ 2026-01-07 15:24 UTC (permalink / raw)
  To: Stuart Campbell <[email protected]>; pgsql-general

On 1/7/26 02:32, Stuart Campbell wrote:
> Hi there,
> 

> I'm working in a Ruby on Rails application where the schema is 
> periodically dumped to a structure.sql file on disk. So, it would be 
> convenient if the constraint definition was "stable" (otherwise, there's 
> unnecessary noise in our version control history)
> 
> Is it expected that the second form is rewritten into the third form? It 
> seems a bit odd to see all the type casting going on, but maybe there is 
> a good reason for that. (Maybe this is an issue with using varchar 
> instead of text?)

https://www.postgresql.org/docs/current/datatype-character.html

"text is PostgreSQL's native string data type, in that most built-in 
functions operating on strings are declared to take or return text not 
character varying. For many purposes, character varying acts as though 
it were a domain over text."


When you did the dump/restore cycles where they from and to the same 
Postgres version/instance?

> 
> 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.
> 
> 


-- 
Adrian Klaver
[email protected]






^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: Unexpected modification of check constraint definition
  2026-01-07 15:24 Re: Unexpected modification of check constraint definition Adrian Klaver <[email protected]>
@ 2026-01-07 21:59 ` Stuart Campbell <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Stuart Campbell @ 2026-01-07 21:59 UTC (permalink / raw)
  To: Adrian Klaver <[email protected]>; +Cc: pgsql-general

On Thu, Jan 8, 2026 at 2:24 AM Adrian Klaver <[email protected]>
wrote:

> https://www.postgresql.org/docs/current/datatype-character.html
>
> "text is PostgreSQL's native string data type, in that most built-in
> functions operating on strings are declared to take or return text not
> character varying. For many purposes, character varying acts as though
> it were a domain over text."


Thanks. It seems like I should generally prefer to use text over varchar.
(I've read advice along those lines elsewhere.)


> When you did the dump/restore cycles where they from and to the same
> Postgres version/instance?


Yes. In the example I provided, that was all from the same Postgres 16.4
instance.

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.






^ permalink  raw  reply  [nested|flat] 2+ messages in thread

end of thread, other threads:[~2026-01-07 21:59 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-01-07 15:24 Re: Unexpected modification of check constraint definition Adrian Klaver <[email protected]>
2026-01-07 21:59 ` Stuart Campbell <[email protected]>

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