| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Dunstan | 2008-04-28 11:49:32 | Re: Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing |
| Previous Message | User Jbcooley | 2008-04-28 01:55:01 | npgsql - Npgsql2: Added tests for System.Transactions |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marko Kreen | 2008-04-28 08:57:39 | Re: MERGE Specification |
| Previous Message | Simon Riggs | 2008-04-28 08:52:17 | Re: MERGE Specification |