Re: Add column if not exists (CINE)

robertmhaas(at)gmail(dot)com (Robert Haas) writes:
> On Wed, Apr 28, 2010 at 1:40 PM, Dimitri Fontaine
> <dfontaine(at)hi-media(dot)com> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> Well, how would you define CREATE OR REPLACE TABLE?  I think that
>>> doesn't make much sense, which is why I think CREATE IF NOT EXISTS is
>>> a reasonable approach.
>>
>> <hand waving time>
>>
>> The behavior I'd like to have would be to allow me to give a SELECT
>> query to run for replacing what is there if there's something. If the
>> query can not be run on the existing data set, error out of course.
>>
>> So you know the state for sure after the command, but it depends on your
>> query being correct. And you can (de)normalize existing data using joins.
>>
>> The REPLACE keyword would here mean that there's a CTAS going under the
>> hood, then we add the constraints and indexes and triggers etc. That
>> would mean being able to express those entities changes too, but it
>> seems important.
>>
>> Well, that may be not precise enough as a spec, but at least that's food
>> for though I hope.
>
> This type of hand-waving convinces me more than ever that we should
> just implement CINE, and it should just C if it doesn't already E.
> This is what has been requested multiple times, by multiple people,
> including various people who don't normally poke their head into
> -hackers. I think the resistance to a straightforward implementation
> with easy-to-understand behavior is completely unjustifiable. It's
> completely unobvious to me that all of the above will work at all and,
> if it did, whether it would actually solve the problems that I care
> about, like being able to write schema-upgrade scripts that would work
> in a simple and predictable fashion.

I tend to agree with you here.

While yes, "CINE is a simplification of COR (CREATE OR REPLACE)", I'm
not at all sure that it's reasonable to hope for the latter, in that it
elides potentially grave problems that aren't reasonable to expect
solved.

Notably, the "and what if a substantial data transformation is needed to
accomplish this?"

CINE doesn't propose to try to do that transformation, which seems like
the right choice to me.

When I put my "we've got things replicating using Slony-I" hat on, CINE
looks pretty preferable to me. It's unambitious - but it is certainly
NOT doing a bunch of magic behind your back so as to make it tougher to
predict what might happen in a trigger-replicated environment.

In any case, CINE seems pretty useful to me. I'm prepared to listen to
persuasion, but thus far, it looks like a "+1 from me."

An alternative that seems likable is "COR, raising an exception if
there's a type mismatch." Where there's certainly room to debate how
much of a difference represents a "mismatch."
--
"cbbrowne","@","gmail.com"
http://linuxfinances.info/info/wp.html
Predestination was doomed from the start.