--- Den fre 2010-04-30 skrev Bruce Momjian <br...@momjian.us>:
> Tom Lane wrote:
> > Robert Haas <robertmh...@gmail.com>
> writes:
> > > We can artificially make this problem as
> complicated as we wish, but
> > > the people who are asking for this feature
> (including me) will, I
> > > believe, be quite happy with a solution that
> throws, say, a NOTICE
> > > instead of an ERROR when the object already
> exists, and then returns
> > > without doing anything further.  There are
> very few, if any,
> > > definitional issues here, except by people who
> are brainstorming crazy
> > > alternative behaviors whose actual usefulness I
> very much doubt.
> > 
> > > CREATE OR REPLACE is indeed much more
> complicated.  In fact, for
> > > tables, I maintain that you'll need to link with
> -ldwim to make it
> > > work properly.
> > 
> > This may in fact be an appropriate way to handle the
> case for tables,
> > given the complexity of their definitions. 
> However, the original
> > point of the thread was about what to do for
> columns.  I still say
> > that COR rather than CINE semantics would be
> appropriate for columns.
> 
> I have added this TODO item:
> 
>     Allow CREATE TABLE to optionally create
> a table if it does not already
>     exist, without throwing an error
>     
>         The fact that tables
> contain data makes this more complex than other
>     CREATE OR REPLACE operations.

If you could write a COR for columns, then a COR for tables would be 
90% done by calling COR on each column and drop/keep the rest (COR 
WITH/WITHOUT DROP?). You'd have to deal with table constraints but you 
also have to handle column constraints to do COR on columns. 

In other words, pretty much all the hard bits I seem to hear people agree 
on exist still apply to the single column. COR for columns was suggested 
already back in the same thread in 2005:

http://archives.postgresql.org/pgsql-hackers/2005-10/msg00644.php

We're already talking 2010, what I fear is that COR is that shiny goal 
far, far out there but if I come back in 2015 there'll still be neither 
COR or CINE. I really can't understand how CINE can be equally hard to 
implement as COR, since CINE is simply to NOT throw an error.

Regards,
Kjell Rune



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to