On Wed, Apr 28, 2010 at 9:58 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@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
