Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

2018-07-04 23:17 GMT+02:00 Tom Lane : > Robert Haas writes: > > Another possibility that would also seem to meet the OP's needs is to > > make it do this: > > > DROP TABLE IF EXISTS X; > > NOTICE: relation "X" is not a table, skipping > > > His complaint was really that it generated an ERROR,

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Wednesday, July 4, 2018, Tom Lane wrote: > > Also, based on other messages, it seems like what the OP wants is > to be sure that "CREATE TABLE X" will succeed afterwards, so that > failing to get rid of view X will not do what he needs. > I read and agree that what should be possible, absent

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

Robert Haas writes: > Another possibility that would also seem to meet the OP's needs is to > make it do this: > DROP TABLE IF EXISTS X; > NOTICE: relation "X" is not a table, skipping > His complaint was really that it generated an ERROR, IIUC. While that would perhaps meet the OP's desires,

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Mon, Jul 2, 2018 at 10:33 PM, Robert Haas wrote: > Yes, the original proposal was that we should be relaxed about it. ...in both directions i.e. DROP TABLE would work on a VIEW and DROP VIEW on a table. That definitely seems like it's going too far. > Another possibility that would also

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Mon, Jul 2, 2018 at 5:25 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jun 26, 2018 at 1:06 PM, Tom Lane 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

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

Robert Haas writes: > On Tue, Jun 26, 2018 at 1:06 PM, Tom Lane 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 >>

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On 28 June 2018 at 05:37, Peter Moser wrote: [] > In general my use-case is, that I want to delete an X in a certain > namespace, where the type is not known in advance. I could query the > catalog to get that information and then build a procedure to "execute" the > right DROP command (as

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On 06/26/2018 07:06 PM, Tom Lane wrote: Also worth noting is that similar issues arise elsewhere, eg we now have "procedures" vs "functions" in a single namespace. Let's not have DROP TABLE acting in a way that's inconsistent with other parts of the system. I think, that DROP ... could

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tue, Jun 26, 2018 at 10:06 AM, Tom Lane wrote: > Pavel Stehule writes: > > 2018-06-26 18:22 GMT+02:00 David G. Johnston >: > >>> So I am not sure, if proposed change is practical because views and > >>> tables shares same namespace and current behave has sense too. > > >> I'm doubtful that

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

Pavel Stehule writes: > 2018-06-26 18:22 GMT+02:00 David G. Johnston : >>> So I am not sure, if proposed change is practical because views and >>> tables shares same namespace and current behave has sense too. >> I'm doubtful that there is any meaningful technical/practical challenge >> involved

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tuesday, June 26, 2018, Pavel Stehule wrote: > > Just I don't see this proposal as clean win. More it is not limited only > this case. It should be consistent with DROP INDEX, SEQUENCE, ... > Yes, they are likely all broken in the same way and whomever agrees with the "it's bugged"

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

2018-06-26 18:22 GMT+02:00 David G. Johnston : > On Tuesday, June 26, 2018, Pavel Stehule wrote: >> >> My note is related to @b. I understand to the motivation, but I am not >> sure if it is good idea. Tables and views shares one namespace. >> > > But the command say "drop table" and so it must

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tuesday, June 26, 2018, Pavel Stehule wrote: > > My note is related to @b. I understand to the motivation, but I am not > sure if it is good idea. Tables and views shares one namespace. > But the command say "drop table" and so it must only be concerned with that subset of the namespace when

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

2018-06-26 17:48 GMT+02:00 David G. Johnston : > On Tuesday, June 26, 2018, Pavel Stehule wrote: > >> 2018-06-26 17:23 GMT+02:00 Peter Moser : >> >>> Hi, >>> I want to delete a table X, that may not exist, hence I execute >>> >>> DROP TABLE IF EXISTS X; >>> >>> However, if X is a view, I

Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On Tuesday, June 26, 2018, Pavel Stehule wrote: > 2018-06-26 17:23 GMT+02:00 Peter Moser : > >> Hi, >> I want to delete a table X, that may not exist, hence I execute >> >> DROP TABLE IF EXISTS X; >> >> However, if X is a view, I get an error >> >> ERROR: "X" is not a table >> >

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

On 06/26/2018 05:34 PM, Pavel Stehule wrote: 2018-06-26 17:23 GMT+02:00 Peter Moser >: What do you think, is it worth to create a patch to solve this issue, where a DROP TABLE does not fail, if the given name is actually a VIEW or vice-versa? DROP TABLE

Re: Unexpected behavior of DROP VIEW/TABLE IF EXISTS

2018-06-26 17:23 GMT+02:00 Peter Moser : > Hi, > I want to delete a table X, that may not exist, hence I execute > > DROP TABLE IF EXISTS X; > > However, if X is a view, I get an error > > ERROR: "X" is not a table > HINT: Use DROP VIEW to remove a view. > SQL

Unexpected behavior of DROP VIEW/TABLE IF EXISTS

Hi, I want to delete a table X, that may not exist, hence I execute DROP TABLE IF EXISTS X; However, if X is a view, I get an error ERROR: "X" is not a table HINT: Use DROP VIEW to remove a view. SQL state: 42809 That is unexpected and also difficult to handle,