Add column if not exists (CINE)
in [PgSql]
|
From: Bernd Helmle on 21 Jul 2010 14:53 --On 1. Mai 2010 23:09:23 -0400 Robert Haas <robertmhaas(a)gmail.com> wrote: > On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane <tgl(a)sss.pgh.pa.us> 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 complexity of their definitions. > > Patch attached. > I had an initial look at Robert's patch. Patch applies cleanly, documentation and regression tests included, everything works as expected. When looking at the functionality there's one thing that strikes me a little: bernd(a)localhost:bernd #*= CREATE TABLE IF NOT EXISTS foo(id int); ERROR: duplicate key value violates unique constraint "pg_type_typname_nsp_index" DETAIL: Key (typname, typnamespace)=(foo, 2200) already exists. This is what you get from concurrent CINE commands. The typname thingie might be confusing by unexperienced users, but i think its hard to do anything about it ? -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 21 Jul 2010 17:16 On Wed, Jul 21, 2010 at 2:53 PM, Bernd Helmle <mailings(a)oopsware.de> wrote: > > > --On 1. Mai 2010 23:09:23 -0400 Robert Haas <robertmhaas(a)gmail.com> wrote: > >> On Wed, Apr 28, 2010 at 9:15 PM, Tom Lane <tgl(a)sss.pgh.pa.us> 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 complexity of their definitions. >> >> Patch attached. > > I had an initial look at Robert's patch. Patch applies cleanly, > documentation and regression tests included, everything works as expected. > When looking at the functionality there's one thing that strikes me a > little: > > bernd(a)localhost:bernd #*= CREATE TABLE IF NOT EXISTS foo(id int); > ERROR: �duplicate key value violates unique constraint > "pg_type_typname_nsp_index" > DETAIL: �Key (typname, typnamespace)=(foo, 2200) already exists. > > This is what you get from concurrent CINE commands. The typname thingie > might be confusing by unexperienced users, but i think its hard to do > anything about it ? 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); <blocks> S1: rhaas=# commit; COMMIT S2: ERROR: duplicate key value violates unique constraint "pg_type_typname_nsp_index" DETAIL: Key (typname, typnamespace)=(foo, 2200) already exists. I agree it would be nice to fix this. I'm not sure how hard it is. I don't think it's the job of this patch. :-) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 21 Jul 2010 20:43 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 the command will run for. As a DBA, I would want a command that executes without rewrite (if appropriate) or does nothing. Predictable behaviour is the most important concern. That isn't necessarily an argument in favour of CINE, which seems slightly less clear about what we might expect from that, in my reading at least. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bernd Helmle on 23 Jul 2010 02:46 --On 21. Juli 2010 17:16:13 -0400 Robert Haas <robertmhaas(a)gmail.com> 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); > <blocks> > > S1: > rhaas=# commit; > COMMIT > > S2: > ERROR: duplicate key value violates unique constraint > "pg_type_typname_nsp_index" > DETAIL: Key (typname, typnamespace)=(foo, 2200) already exists. > Funny, never realized that before, but you're right. > I agree it would be nice to fix this. I'm not sure how hard it is. I > don't think it's the job of this patch. :-) 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). Given that there's still some discussion in progress, i'm not sure about it, however. The patch itself looks fine to me and I'm traveling this weekend, so i don't want to hold it off as long as necessary. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 23 Jul 2010 07:06 On Fri, Jul 23, 2010 at 2:46 AM, Bernd Helmle <mailings(a)oopsware.de> wrote: > > > --On 21. Juli 2010 17:16:13 -0400 Robert Haas <robertmhaas(a)gmail.com> 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); >> <blocks> >> >> S1: >> rhaas=# commit; >> COMMIT >> >> S2: >> ERROR: �duplicate key value violates unique constraint >> "pg_type_typname_nsp_index" >> DETAIL: �Key (typname, typnamespace)=(foo, 2200) already exists. >> > > Funny, never realized that before, but you're right. > >> I agree it would be nice to fix this. �I'm not sure how hard it is. �I >> don't think it's the job of this patch. �:-) > > 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). Given that there's still some discussion in progress, i'm not > sure about it, however. The patch itself looks fine to me and I'm traveling > this weekend, so i don't want to hold it off as long as necessary. As far as I can see, the other emails were regarding adding columns, whereas this patch is about creating tables. So I think it's OK... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 Prev: [HACKERS] documentation for committing with git Next: documentation for committing with git |