On Thu, Jul 22, 2010 at 4:34 PM, Kjell Rune Skaaraas wrote:
> At least from a performance point of view CINE should never cause a table
> rewrite, it should either execute as a plain CREATE or as "nothing". I don't
> mind if the CINE fails if the column already exists but with a different
> def
On Fri, Jul 23, 2010 at 2:46 AM, Bernd Helmle wrote:
> Yes, i agree. I would like to mark this patch "Ready for Committer", if
> that's okay for you (since you are a committer you might want to commit it
> yourself).
I see that it is so marked, so, committed, with a minor correction to
my origina
On Fri, Jul 23, 2010 at 2:46 AM, Bernd Helmle wrote:
>
>
> --On 21. Juli 2010 17:16:13 -0400 Robert Haas wrote:
>
>> I get the same error message from concurrent CREATE TABLE commands
>> even without CINE...
>>
>> S1:
>> rhaas=# begin;
>> BEGIN
>> rhaas=# create table foo (id int);
>> CREATE TABL
--On 21. Juli 2010 17:16:13 -0400 Robert Haas wrote:
I get the same error message from concurrent CREATE TABLE commands
even without CINE...
S1:
rhaas=# begin;
BEGIN
rhaas=# create table foo (id int);
CREATE TABLE
S2:
rhaas=# begin;
BEGIN
rhaas=# create table foo (id int);
S1:
rhaas=# com
on maybe this sounds better. The syntax
leaves it open for COR later, and the matching code should be useful to
determine if the COR actually needs to do a REPLACE. Opinions?
Regards,
Kjell Rune
--- Den tor 2010-07-22 skrev Simon Riggs :
> Fra: Simon Riggs
> Emne: Re: [HACKERS] Add
On Wed, 2010-04-28 at 21:15 -0400, Tom Lane wrote:
> I still say
> that COR rather than CINE semantics would be appropriate for columns.
Viewed from a locking perspective, I would disagree.
COR semantics force a table rewrite, in certain cases. That makes it
hard to predict externally how long t
On Wed, Jul 21, 2010 at 2:53 PM, Bernd Helmle wrote:
>
>
> --On 1. Mai 2010 23:09:23 -0400 Robert Haas wrote:
>
>> On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane wrote:
CREATE OR REPLACE is indeed much more complicated. In fact, for
tables, I maintain that you'll need to link with -ld
--On 1. Mai 2010 23:09:23 -0400 Robert Haas wrote:
On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane wrote:
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
--- Den fre 2010-04-30 skrev Bruce Momjian :
> Tom Lane wrote:
> > Robert Haas
> 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
> throw
On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane wrote:
>> 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 complex
On Sat, May 1, 2010 at 2:26 PM, Kjell Rune Skaaraas wrote:
> 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-hack
Tom Lane wrote:
> Robert Haas 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 alread
robertmh...@gmail.com (Robert Haas) writes:
> On Wed, Apr 28, 2010 at 1:40 PM, Dimitri Fontaine
> wrote:
>> Robert Haas 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
Robert Haas 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
On Wed, Apr 28, 2010 at 2:57 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Robert Haas wrote:
>>> Well, how would you define CREATE OR REPLACE TABLE?
>
>> It the table doesn't exist, create it. If it exists with the same name
>> and same columns and constraints and all, do nothing. Otherwis
Heikki Linnakangas writes:
> Robert Haas wrote:
>> Well, how would you define CREATE OR REPLACE TABLE?
> It the table doesn't exist, create it. If it exists with the same name
> and same columns and constraints and all, do nothing. Otherwise throw an
> error.
> Maybe it should also check that th
--- Den ons 2010-04-28 skrev Tom Lane :
> Fra: Tom Lane
> Emne: Re: [HACKERS] Add column if not exists (CINE)
> Til: "Robert Haas"
> Kopi: "Andrew Dunstan" , "Takahiro Itagaki"
> , "Kjell Rune Skaaraas" ,
> pgsql-hackers@postgr
Robert Haas wrote:
> On Wed, Apr 28, 2010 at 12:07 PM, Heikki Linnakangas
> wrote:
>> Robert Haas wrote:
>>> On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane wrote:
Robert Haas writes:
> I don't believe you are fairly stating the consensus from previous
> discussion and I believe that you
Robert Haas 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.
The behavior I'd like to have would be to allow me to give a SELECT
query to run for replacing what is there i
On Wed, Apr 28, 2010 at 1:40 PM, Dimitri Fontaine
wrote:
> Robert Haas 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.
>
>
>
> The behavior I'd like to have would be to
On Wed, Apr 28, 2010 at 12:07 PM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane wrote:
>>> Robert Haas writes:
I don't believe you are fairly stating the consensus from previous
discussion and I believe that you are actually in the minorit
Robert Haas writes:
> Actually, that's a good idea. But how will you handle tables?
Well, tables are a special case, mainly because it's not clear how to
avoid accidentally throwing away data. (In particular if some column in
the existing table isn't there in the new definition. It's a bit sca
Robert Haas wrote:
On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane wrote:
Robert Haas writes:
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 thi
Robert Haas wrote:
> On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> 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
On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane wrote:
> Robert Haas writes:
>> 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
Tom Lane wrote:
> Robert Haas writes:
>> 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 avai
Robert Haas writes:
> 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
>
On Wed, Apr 28, 2010 at 9:58 AM, Tom Lane wrote:
> Andrew Dunstan 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 shoul
On Tue, Apr 27, 2010 at 08:18:13PM -0400, Robert Haas wrote:
> On Tue, Apr 27, 2010 at 6:45 PM, Kjell Rune Skaaraas
> wrote:
[snip]
> > I saw some indications that this might be a minority opinion, well I would
> > like to cast a vote FOR this functionality. The workarounds are ugly, the
> > so
Andrew Dunstan 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
Takahiro Itagaki wrote:
Kjell Rune Skaaraas wrote:
I've been reading the earlier threads at:
http://archives.postgresql.org/pgsql-hackers/2009-05/thrd7.php#00252
http://archives.postgresql.org/pgsql-hackers/2005-10/thrd4.php#00632
and I'm not sure I have anything that substantially new to
Kjell Rune Skaaraas wrote:
> I've been reading the earlier threads at:
> http://archives.postgresql.org/pgsql-hackers/2009-05/thrd7.php#00252
> http://archives.postgresql.org/pgsql-hackers/2005-10/thrd4.php#00632
> and I'm not sure I have anything that substantially new to add but:
>
> I saw so
On Tue, Apr 27, 2010 at 6:45 PM, Kjell Rune Skaaraas wrote:
> Hello,
>
> I've been reading the earlier threads at:
> http://archives.postgresql.org/pgsql-hackers/2009-05/thrd7.php#00252
> http://archives.postgresql.org/pgsql-hackers/2005-10/thrd4.php#00632
> and I'm not sure I have anything that s
Hello,
I've been reading the earlier threads at:
http://archives.postgresql.org/pgsql-hackers/2009-05/thrd7.php#00252
http://archives.postgresql.org/pgsql-hackers/2005-10/thrd4.php#00632
and I'm not sure I have anything that substantially new to add but:
1. I can't see there's an unambiguity abou
34 matches
Mail list logo
