On Mon, Apr 28, 2008 at 2:24 PM, Zeugswetter Andreas OSB SD
<[EMAIL PROTECTED]> wrote:
> I think you are not considering existing btree indexes here
> (for the reordering case) ?
You're quite right, I had not considered existing indexes. There's no
easy way to deal with that other than rebuildin
> 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.
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Another alternative would be internally creating a different temporary
>> enum, rewriting the tables one by one each on its own transaction, and
>> finish by dropping the original enum and renaming the temporary one.
>> This solv
Alvaro Herrera wrote:
Andrew Dunstan escribió:
Tom Dunstan wrote:
So two alternative proposals, both with a 2 byte "enum id" and a 2 byte "value":
1 - We space the values out as evenly as we can across the 65000ish
range and allow people to delete, insert and append, but not reorder
Andrew Dunstan escribió:
> Tom Dunstan wrote:
>> So two alternative proposals, both with a 2 byte "enum id" and a 2 byte
>> "value":
>>
>> 1 - We space the values out as evenly as we can across the 65000ish
>> range and allow people to delete, insert and append, but not reorder.
>> If they do the
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> On Sat, Apr 26, 2008 at 2:51 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Further, as already noted, if you do have to rewrite then a series of
>> manual ALTER COLUMN TYPE operations would probably be a *better* answer
>> than a monolithic implementation, b
On Sat, Apr 26, 2008 at 2:51 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm not ... it strikes me that it will add implementation complexity and
> runtime overhead for a feature that two days ago we didn't think we
> needed at all, and IMHO one we still shouldn't be thinking to expend a
> lot of
Tom Dunstan wrote:
So two alternative proposals, both with a 2 byte "enum id" and a 2 byte "value":
1 - We space the values out as evenly as we can across the 65000ish
range and allow people to delete, insert and append, but not reorder.
If they do the above gratuitously we might have to do a
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> 1 - We space the values out as evenly as we can across the 65000ish
> range and allow people to delete, insert and append, but not reorder.
> If they do the above gratuitously we might have to do a rewrite, but
> they'll have to get fairly busy to do it.
Oops, sorry for the crossed emails, slight delay in my main being received.
On Sat, Apr 26, 2008 at 2:18 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I think with something like your 16bit/16bit design, and say ten free
> codes between each original assignment, it'd be okay to not support the
> re
On Sat, Apr 26, 2008 at 2:07 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > The very first idea that I had was to have an enum value as
> > the combination of both an enum id and the ordinal value.
>
> I seem to remember that we discussed that and rejected it, but I don't
> remember the reasoning.
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On Sat, Apr 26, 2008 at 6:33 AM, Tom Dunstan wrote:
>> I've already suggested some alternatives in the reply to Brendan that
>> would solve some of this, but I suppose another gross-seeming way to
>> stop surprise rewrites would be to never do one unles
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 6:33 AM, Tom Dunstan wrote:
> One scenario I'm not happy about is this: the friendly db admin has
> happily added an extra value to the end before and the operation has
> been a snap - no rewriting required. But this time ei
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> One scenario I'm not happy about is this: the friendly db admin has
> happily added an extra value to the end before and the operation has
> been a snap - no rewriting required. But this time either a) oid
> wraparound has occurred, b) she's inserted one
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> I wonder if it's worth revisiting the decision to save enums on disk
> as oids. The very first idea that I had was to have an enum value as
> the combination of both an enum id and the ordinal value. We would
> presumably make both say 16bits so we could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 6:19 AM, Tom Dunstan wrote:
> I wonder if it's worth revisiting the decision to save enums on disk
> as oids. The very first idea that I had was to have an enum value as
> the combination of both an enum id and the ordinal v
On Fri, Apr 25, 2008 at 11:57 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> We already support rewriting tables ... (albeit only one at a time, I
> admit. Doing it for more than one can cause deadlocks).
>
> Still, if the user wants to pay the cost, why should we prohibit it?
One scenario I'
Brendan Jurd escribió:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Apr 26, 2008 at 6:02 AM, Tom Lane wrote:
> > "Brendan Jurd" writes:
> > > Has anyone had a close look at how hard it would be allow just the
> > > "add to the end" capability?
> >
> > The problem is you can't
On Sat, Apr 26, 2008 at 12:10 AM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> Has anyone had a close look at how hard it would be allow just the
> "add to the end" capability?
If the OIDs haven't wrapped around since the enum was created, it's
trivial. If they have, well someone with more OID-fu t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 6:02 AM, Tom Lane wrote:
> "Brendan Jurd" writes:
> > Has anyone had a close look at how hard it would be allow just the
> > "add to the end" capability?
>
> The problem is you can't guarantee anything about the ordering of
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> Has anyone had a close look at how hard it would be allow just the
> "add to the end" capability?
The problem is you can't guarantee anything about the ordering of the
new value relative to the old ones. The OID it's assigned might be
after them, or be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 4:27 AM, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
> >
> > Bruce Momjian wrote:
> >> Log Message:
> >> ---
> >> Update:
> >>
> >> >>
> >>> * Allow adding/removing enumerated values to an existing enumerate
Andrew Dunstan wrote:
>
> Bruce Momjian wrote:
>> Log Message:
>> ---
>> Update:
>>
>> < * Allow adding enumerated values to an existing enumerated data
>>
>>> * Allow adding/removing enumerated values to an existing enumerated data
>
> Where did this come from? Adding values anywhere ex
23 matches
Mail list logo
