Re: pg_restore casts check constraints differently

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joshua Ma <josh(at)benchling(dot)com>
Cc: PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org>, Victor Pontis <victor(at)benchling(dot)com>
Subject: Re: pg_restore casts check constraints differently
Date: 2016-03-29 21:45:52
Message-ID: 30073.1459287952@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Joshua Ma <josh(at)benchling(dot)com> writes:
> This might not be a common case, but we're using pg_dump in a testing
> environment to check migrations - 1) we initialize the db from HEAD,
> pg_dump it, 2) we initialize the db from migration_base.sql, apply
> migrations, pg_dump it, and 3) compare the two dumps to verify that our
> migrations are correct wrt schema.

> However, we're seeing pg_restore transforming our check constraints with
> different casting.

It's not really different. What you're seeing is pg_dump (or actually
ruleutils.c) choosing to dump some implicit casts explicitly to ensure
that the expression is parsed the same way next time. It might be
overly conservative to do so, but we've found that erring in this
direction tends to avoid breakage when the result is loaded into another
server version; it's a bit like the intentional overparenthesization.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2016-03-29 22:06:05 Re: pg_restore casts check constraints differently
Previous Message Joshua Ma 2016-03-29 21:05:47 pg_restore casts check constraints differently

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2016-03-29 21:47:53 Re: Proposal: "Causal reads" mode for load balancing reads without stale data
Previous Message Alvaro Herrera 2016-03-29 21:44:50 standby_schedule