| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Peter Moser <pitiz29a(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS |
| Date: | 2018-07-02 18:43:04 |
| Message-ID: | CA+TgmoatNUT0mDt8ekEFp9RJQQ+Esa3vvPow+5RXDvwe-vY0RQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 26, 2018 at 1:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Certainly we *could* change it, but it's not at all clear that it's a good
> idea. The current behavior seemed sensible when it was implemented, and
> it has stood for quite some years now. Now, we have one person
> complaining that it wasn't what he expected. If we change the behavior on
> the strength of that, will we change it back on the first complaint from
> someone else? What about the possibility that the change breaks peoples'
> applications?
Hmm. I think we generally allow ALTER TABLE to work on non-table
relations. For example, ALTER TABLE .. OWNER TO happily accepts a
view or materialized view as an argument. I have had my doubts about
that policy from time to time (cf.
1489e2f26a4c0318938b3085f50976512f321d84) but it does seem to be the
policy (cf. b14206862278347a379f2bb72d92d16fb9dcea45). Is there some
reason to think that the same policy that we apply to ALTER should not
also apply to DROP?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2018-07-02 19:13:15 | Re: Speedup of relation deletes during recovery |
| Previous Message | Robert Haas | 2018-07-02 18:27:20 | Re: Add --include-table-data-where option to pg_dump, to export only a subset of table data |