Takahiro Itagaki wrote:
Kjell Rune Skaaraas <kjell...@yahoo.no> wrote:
I've been reading the earlier threads at:
http://archives.postgresql.org/pgsql-hackers/2009-05/thrd7.php#00252
http://archives.postgresql.org/pgsql-hackers/2005-10/thrd4.php#00632
and I'm not sure I have anything that substantially new to add but:
I saw some indications that this might be a minority opinion,
well I would like to cast a vote FOR this functionality.
+1 for CINE, just because MySQL supports it.
MySQL compatibility has never been our aim. We should adopt ideas from
other projects because they are good, not just because they are there.
That doesn't mean I don't think this is a good idea.
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? Since we would
presumably want to do this for all (or almost all) of our CREATE/ADD
commands, we'd need a policy on those.
Also, developers should consider not only ADD COLUMN but also other
CREATE or ADD commands. The patch will be large, including documentation
adjustments in many places -- it would be hard work.
I can speak with some experience on this at least. :-) I don't see that
it would be a heck of a lot bigger than the DROP IF EXISTS cases, which
after the first few had been done were not hard, merely tedious to do :-)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
