Add column if not exists (CINE)
in [PgSql]
|
Prev: [HACKERS] road.thepath no longer in pg_stats?
Next: providing tokenized version of parsed SQL script (was: nodeToString format and exporting the SQL parser)
From: Robert Haas on 28 Apr 2010 11:14 On Wed, Apr 28, 2010 at 9:58 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Andrew Dunstan <andrew(a)dunslane.net> writes: >> Takahiro Itagaki wrote: >>> But before developing, we need to decide how to handle an added object >>> that has the same name but has different definitions. > >> The OP explicitly stated that in his opinion nothing should be done in >> such cases. That's a defensible position, in the case of objects such as >> tables that must be unique by name (e.g. tables). But what would we do >> about objects where the name could be overloaded? > > Even if it's defensible, the consensus position so far has been that > it's a bad design. Every time we've looked at this, we have concluded > that CREATE OR REPLACE semantics are considerably safer to use, because > there is no question what the state of the object is afterwards. That > argument is just as valid for a column as for anything larger. > > AFAICS, the only excuse CINE has for living is that (people think) > it would take less work to implement. I don't believe you are fairly stating the consensus from previous discussion and I believe that you are actually in the minority on this one. I agree that we probably don't need to support this for object types for which CREATE OR REPLACE is available or can be made available, but that isn't feasible for all object types - tables and columns being the obvious examples. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 28 Apr 2010 11:20 Robert Haas <robertmhaas(a)gmail.com> writes: > I don't believe you are fairly stating the consensus from previous > discussion and I believe that you are actually in the minority on this > one. I agree that we probably don't need to support this for object > types for which CREATE OR REPLACE is available or can be made > available, but that isn't feasible for all object types - tables and > columns being the obvious examples. What's obvious about it? In particular, I should think that ADD OR REPLACE COLUMN would usefully be defined as "ADD if no such column, else ALTER COLUMN as necessary to match this spec". Dropping the ALTER part of that has no benefit except to lazy implementors; it certainly is not more useful to users if they can't be sure of the column properties after issuing the command. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 28 Apr 2010 11:30 Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> I don't believe you are fairly stating the consensus from previous >> discussion and I believe that you are actually in the minority on this >> one. I agree that we probably don't need to support this for object >> types for which CREATE OR REPLACE is available or can be made >> available, but that isn't feasible for all object types - tables and >> columns being the obvious examples. > > What's obvious about it? In particular, I should think that ADD OR > REPLACE COLUMN would usefully be defined as "ADD if no such column, > else ALTER COLUMN as necessary to match this spec". Dropping the > ALTER part of that has no benefit except to lazy implementors; it > certainly is not more useful to users if they can't be sure of the > column properties after issuing the command. Right. A trivial implementation of CREATE OR REPLACE is to create the object if it doesn't exist, do nothing if it exists already and is identical to the new definition, and throw an error if it's not identical. That covers the same use case as CREATE IF NOT EXISTS, but you know what the state is after a successful execution, is easy to implement, and is in line with the existing CREATE OR REPLACE commands. And can be extended in the future to alter the existing object instead of throwing an error. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 28 Apr 2010 12:03 On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> I don't believe you are fairly stating the consensus from previous >> discussion and I believe that you are actually in the minority on this >> one. I agree that we probably don't need to support this for object >> types for which CREATE OR REPLACE is available or can be made >> available, but that isn't feasible for all object types - tables and >> columns being the obvious examples. > > What's obvious about it? In particular, I should think that ADD OR > REPLACE COLUMN would usefully be defined as "ADD if no such column, > else ALTER COLUMN as necessary to match this spec". Dropping the > ALTER part of that has no benefit except to lazy implementors; it > certainly is not more useful to users if they can't be sure of the > column properties after issuing the command. Actually, that's a good idea. But how will you handle tables? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 28 Apr 2010 12:07
Robert Haas wrote: > On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas(a)gmail.com> writes: >>> I don't believe you are fairly stating the consensus from previous >>> discussion and I believe that you are actually in the minority on this >>> one. I agree that we probably don't need to support this for object >>> types for which CREATE OR REPLACE is available or can be made >>> available, but that isn't feasible for all object types - tables and >>> columns being the obvious examples. >> What's obvious about it? In particular, I should think that ADD OR >> REPLACE COLUMN would usefully be defined as "ADD if no such column, >> else ALTER COLUMN as necessary to match this spec". Dropping the >> ALTER part of that has no benefit except to lazy implementors; it >> certainly is not more useful to users if they can't be sure of the >> column properties after issuing the command. > > Actually, that's a good idea. But how will you handle tables? What do you mean? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |