| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | firstname lastname <ceccareb(at)talusmusic(dot)com> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #15263: pg_dump / psql failure. When loading, psql does not see function-based constraints or indices |
| Date: | 2018-07-18 22:10:13 |
| Message-ID: | CAKFQuwa+X47iUN2A-cjLOdB1OR-jxyPvP=a7KoFJNcnLZ1ppKw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Jul 18, 2018 at 2:47 PM, firstname lastname <ceccareb(at)talusmusic(dot)com
> wrote:
> In the end, a person should be able to copy his objects a different
> schema; therefore, one would not want to hard-code a schema name to every
> object.
>
This is basically the issue. By allowing schema to be flexible you expose
your system to masquerading. A more secure, yet still reasonable, posture
is to treat the namespace layout of the database as a fundamental property
of the model. Where that starts to break down is dealing with multi-tenant
situations and trying to have shared and not-shared schema components. Not
sure what the good solutions are if your application wants to operate under
that model - but that affects a minority of people and doesn't seem to be
the case here.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2018-07-19 04:44:33 | Re: BUG #15283: Query Result equal 0 for partitioned table |
| Previous Message | Alvaro Herrera | 2018-07-18 22:04:31 | Re: BUG #15263: pg_dump / psql failure. When loading, psql does not see function-based constraints or indices |