From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexey Bashtanov <bashtanov@imap.cc>
Cc: pgsql-bugs@postgresql.org
Subject: Re: pg_dump losing index column collations for unique and primary keys
Date: Wed, 04 Dec 2019 10:48:58 -0500
Message-ID: <20212.1575474538@sss.pgh.pa.us> (raw)
In-Reply-To: <82921d03-9957-a3e5-09a0-d87b052104b5@imap.cc>
References: <b05ce36a-cefb-ca5e-b386-a400535b1c0b@imap.cc>
<13713.1575392277@sss.pgh.pa.us>
<6484.1575397478@sss.pgh.pa.us>
<d1b13999-3808-8e65-6829-f22bb926206b@imap.cc>
<17844.1575402733@sss.pgh.pa.us>
<82921d03-9957-a3e5-09a0-d87b052104b5@imap.cc>
Alexey Bashtanov <bashtanov@imap.cc> writes:
> What do you think of making pg_dump warn the user if they are trying
> to dump a weird PK/UK which has collations in index and column not matching?
> And maybe even throw an error in case of --binary-upgrade?
I can't get excited about spending any additional effort on this issue.
If I thought it were actually happening in the field to any significant
extent, I'd be more interested in supporting the case instead of just
disallowing it. But I think the actual occurrences are epsilon, so
there are better places to be spending our time.
regards, tom lane
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: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, bashtanov@imap.cc
Subject: Re: pg_dump losing index column collations for unique and primary keys
In-Reply-To: <20212.1575474538@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox