2018-06-26 18:22 GMT+02:00 David G. Johnston <david.g.johns...@gmail.com>:
> On Tuesday, June 26, 2018, Pavel Stehule <pavel.steh...@gmail.com> 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 searching. The note about the view is > helpful, but it shouldn't change whether the command succeeded with a > notice or errors. > > >> Often usage of DROP TABLE IF EXISTS is together with CREATE TABLE >> >> Now if some does bad reference in DROP TABLE command, then this command >> fails (first). If we do proposed change, then DROP TABLE do nothing, and >> CREATE TABLE fails. >> > > Yes, this is what should be happening. CREATE does have to care about the > whole namespace since it creating a new identifier. > > >> 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 here. And as you say when doing paired drop/creates one of them > is going to fail anyway so it doesn't really matter which one. But if > someone wants to convert a table to a view imdompotently (the point if INE) > right now they cannot using the features that are documented to do just > that. > 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, ... Regards Pavel > David J. > >