Skip site navigation (1) Skip section navigation (2)

Re: Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing

From: "Zeugswetter Andreas OSB SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>
To: "Tom Dunstan" <pgsql(at)tomd(dot)cc>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Brendan Jurd" <direvus(at)gmail(dot)com>,"Alvaro Herrera" <alvherre(at)commandprompt(dot)com>,"Andrew Dunstan" <andrew(at)dunslane(dot)net>,"Bruce Momjian" <momjian(at)postgresql(dot)org>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing
Date: 2008-04-28 08:54:06
Message-ID: E1539E0ED7043848906A8FF995BDA579030D3C39@m0143.s-mxs.net (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
> I don't understand this if it's calling option 2 the monolithic
> implementation. I was intending that the values be permanent tokens if
> you like, so that ZERO rewriting would be required for any types of
> modification. So I don't see where locking comes in. I don't want
> rewriting either.

I think you are not considering existing btree indexes here
(for the reordering case) ?

So +1 on a solution that has naturally sorting keys (e.g. your 1). 

Andreas

In response to

Responses

pgsql-hackers by date

Next:From: Marko KreenDate: 2008-04-28 08:57:39
Subject: Re: MERGE Specification
Previous:From: Simon RiggsDate: 2008-04-28 08:52:17
Subject: Re: MERGE Specification

pgsql-committers by date

Next:From: Tom DunstanDate: 2008-04-28 11:49:32
Subject: Re: Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing
Previous:From: User JbcooleyDate: 2008-04-28 01:55:01
Subject: npgsql - Npgsql2: Added tests for System.Transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group