Re: Add column if not exists (CINE)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Kjell Rune Skaaraas <kjella79(at)yahoo(dot)no>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add column if not exists (CINE)
Date: 2010-04-28 13:58:15
Message-ID: 23744.1272463095@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2010-04-28 14:16:55 Re: Error handling for ShmemInitStruct and ShmemInitHash
Previous Message Magnus Hagander 2010-04-28 13:46:39 Re: bug in build_startup_packet()