Takahiro Itagaki wrote:
> Kjell Rune Skaaraas <kjella79(at)yahoo(dot)no> wrote:
>> I've been reading the earlier threads at:
>> 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 :-)
In response to
pgsql-hackers by date
|Next:||From: Fujii Masao||Date: 2010-04-28 12:43:48|
|Subject: bug in build_startup_packet()|
|Previous:||From: Fujii Masao||Date: 2010-04-28 12:18:43|
|Subject: Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct|