From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Felix Ostmann <felix(dot)ostmann(at)gmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: pg_dump ignore CASTs when using --schema |
Date: | 2016-03-04 18:43:27 |
Message-ID: | CAKFQuwbeXMd=KHsjTe2zcdKD8zm_LHi7_PStWw3ZR2EfOMZXgw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Mar 4, 2016 at 11:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Felix Ostmann <felix(dot)ostmann(at)gmail(dot)com> writes:
> > we have a problem with pg_dump and CAST.
>
> Casts don't have names, therefore they don't have schemas, therefore
> a dump that is restricted to a particular schema won't select them.
> So this isn't a bug; it's operating as designed.
>
> This is kind of unfortunate in many scenarios, but it's hard to see a
> principled way around it. You might propose something like pretending
> that a cast is in the same schema as its implementation function, but
> what about casts that have no implementation function? Likewise,
> tying it to the schema of either the input or the output datatype
> seems arbitrary and about as likely to be wrong as right.
>
>
Begs the question - why don't we just name them and allow them to be
placed in a schema?
OR
They have to exist somewhere...can we add an explicit pg_dump option to
target them specifically?
i.e., pg_dump --dump-unnamed
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2016-03-04 19:15:14 | Re: BUG #13920: pg_try_advisory_xact_lock bigint trouble |
Previous Message | Andres Freund | 2016-03-04 18:30:02 | Re: BUG #13844: Logical decoding bug with subxact + row locking |