Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

Emre Hasegeli writes: >> + /* >> +* If the row is hinted as committed, it's surely safe. This provides a >> +* fast path for all normal use-cases. >> +*/ >> + if (HeapTupleHeaderXminCommitted(enumval_tup->t_data)) >> + return; >> + >> + /* >> +*

Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

> Got around to looking at this. Attached is a revised version that I think > is in committable shape. The main non-cosmetic change is that the test > for "type was created in same transaction as new value" now consists of > comparing the xmins of the pg_type and pg_enum rows, without consulting

Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

Andrew Dunstan writes: > OK, did that. Here is a patch that is undocumented but I think is > otherwise complete. It's been tested a bit and we haven't been able to > break it. Comments welcome. Got around to looking at this. Attached is a revised version that I think is

Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

On 04/02/2016 01:20 PM, Tom Lane wrote: Andrew Dunstan writes: Looking at this briefly. It looks like the check should be called from enum_in() and enum_recv(). What error should be raised if the enum row's xmin isn't committed? ERRCODE_FEATURE_NOT_SUPPORTED? or maybe

Re: [HACKERS] Alter or rename enum value

Just stumbled across this thread while looking for something else… > On 28 Mar 2016, at 12:50 AM, Tom Lane wrote: > What you really need is to prevent the new value from being inserted > into any indexes, but checking that directly seems far more difficult, > ugly, and

Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

Andrew Dunstan writes: > Looking at this briefly. It looks like the check should be called from > enum_in() and enum_recv(). What error should be raised if the enum row's > xmin isn't committed? ERRCODE_FEATURE_NOT_SUPPORTED? or maybe > ERRCODE_DATA_EXCEPTION? I don't see

Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

On 03/29/2016 04:56 PM, Andrew Dunstan wrote: On 03/27/2016 10:20 AM, Tom Lane wrote: Andrew Dunstan writes: The more I think about this the more I bump up against the fact that almost anything we do might want to do to ameliorate the situation is going to be rolled

Re: [HACKERS] Alter or rename enum value

On 03/27/2016 10:20 AM, Tom Lane wrote: Andrew Dunstan writes: The more I think about this the more I bump up against the fact that almost anything we do might want to do to ameliorate the situation is going to be rolled back. The only approach I can think of that

Re: [HACKERS] Alter or rename enum value

On 3/28/16 4:42 AM, Emre Hasegeli wrote: Now, we are using a function to replace an enum type on all tables with another one, but we are not at all happy with this solution. It requires all objects which were using the enum to be dropped and recreated, and it rewrites the tables, so it greatly

Re: [HACKERS] Alter or rename enum value

> I do not know whether this would be a meaningful improvement for > common use-cases, though. (It'd help if people were more specific > about the use-cases they need to work.) For what its worth, in the company I am working for, InnoGames GmbH, not being able to alter enums is the number one

Re: [HACKERS] Alter or rename enum value

On Mar 27, 2016, at 7:20 AM, Tom Lane wrote: > I do not know whether this would be a meaningful improvement for > common use-cases, though. It would certainly be a step forward over the current situation. It would mean that a specific imaginable use-case (inserting a new

Re: [HACKERS] Alter or rename enum value

Andrew Dunstan writes: > The more I think about this the more I bump up against the fact that > almost anything we do might want to do to ameliorate the situation is > going to be rolled back. The only approach I can think of that doesn't > suffer from this is to abort if

Re: [HACKERS] Alter or rename enum value

On 03/27/2016 12:43 AM, Christophe Pettus wrote: On Mar 26, 2016, at 7:40 AM, Andrew Dunstan wrote: It would be nice if we could find a less broad brush approach to dealing with the issue. I don't know how doable this is, but could we use the existing mechanism of

Re: [HACKERS] Alter or rename enum value

On Mar 26, 2016, at 7:40 AM, Andrew Dunstan wrote: > It would be nice if we could find a less broad brush approach to dealing with > the issue. I don't know how doable this is, but could we use the existing mechanism of marking an index invalid if it contains an enum type

Re: [HACKERS] Alter or rename enum value

On 03/26/2016 10:25 AM, Tom Lane wrote: Andrew Dunstan writes: We don't have the luxury of being able to redesign this as a green fields development. I'm not actually convinced that we need to do anything. SQL already has a perfectly good mechanism for enforcing that a

Re: [HACKERS] Alter or rename enum value

Andrew Dunstan writes: > We don't have the luxury of being able to redesign this as a green > fields development. I'm not actually convinced that we need to do anything. SQL already has a perfectly good mechanism for enforcing that a column contains only values of a

Re: [HACKERS] Alter or rename enum value

On 03/26/2016 12:35 AM, David G. Johnston wrote: On Friday, March 25, 2016, Andrew Dunstan > wrote: On 03/25/2016 04:13 AM, Matthias Kurz wrote: Hopefully at the commitfest at least the transaction limitation will/could

Re: [HACKERS] Alter or rename enum value

On Friday, March 25, 2016, Andrew Dunstan wrote: > > On 03/25/2016 04:13 AM, Matthias Kurz wrote: > >> >> Hopefully at the commitfest at least the transaction limitation >> will/could be tackled - that would help us a lot already. >> >> > I don't believe anyone knows how to

Re: [HACKERS] Alter or rename enum value

On 03/25/2016 03:22 PM, Christophe Pettus wrote: On Mar 25, 2016, at 11:50 AM, Andrew Dunstan wrote: I don't believe anyone knows how to do that safely. The core issue, for me, is that not being able to modify enum values in a transaction breaks a very wide variety of

Re: [HACKERS] Alter or rename enum value

On 3/25/16 2:22 PM, Gavin Flower wrote: I've certainly heard people avoiding ENUMs because of their limitations, so it'd be nice if there was a way to lift them. Well, I use Enums extensively in Java. However, I totally avoid using ENUMs in pg, due to their inflexibility! Possibly related

Re: [HACKERS] Alter or rename enum value

Andrew Dunstan writes: > On 03/25/2016 04:13 AM, Matthias Kurz wrote: >> >> Hopefully at the commitfest at least the transaction limitation >> will/could be tackled - that would help us a lot already. > > I don't believe anyone knows how to do that safely. Enums pose special

Re: [HACKERS] Alter or rename enum value

On Mar 25, 2016, at 11:50 AM, Andrew Dunstan wrote: > I don't believe anyone knows how to do that safely. The core issue, for me, is that not being able to modify enum values in a transaction breaks a very wide variety of database migration tools. Even a very brutal

Re: [HACKERS] Alter or rename enum value

On 26/03/16 08:17, Jim Nasby wrote: On 3/24/16 10:27 PM, Tom Lane wrote: It's conceivable that we could do something like adding an "isdead" column to pg_enum and making enum_in reject new values that're marked isdead. But I can't see that we'd ever be able to support true removal of an enum

Re: [HACKERS] Alter or rename enum value

On 3/24/16 10:27 PM, Tom Lane wrote: It's conceivable that we could do something like adding an "isdead" column to pg_enum and making enum_in reject new values that're marked isdead. But I can't see that we'd ever be able to support true removal of an enum value at reasonable cost. And I'm not

Re: [HACKERS] Alter or rename enum value

On 03/25/2016 04:13 AM, Matthias Kurz wrote: Hopefully at the commitfest at least the transaction limitation will/could be tackled - that would help us a lot already. I don't believe anyone knows how to do that safely. Enums pose special problems here exactly because unlike all other

Re: [HACKERS] Alter or rename enum value

> > It's conceivable that we could do something like adding an "isdead" > column to pg_enum and making enum_in reject new values that're marked > isdead. But I can't see that we'd ever be able to support true > removal of an enum value at reasonable cost. And I'm not really sure > where the

Re: [HACKERS] Alter or rename enum value

Jim Nasby writes: > I'm certain there's a really good reason adding new values isn't allowed > inside of a transaction. It's probably documented in the code. Yes, see AlterEnum(): * Ordinarily we disallow adding values within transaction blocks, because * we

Re: [HACKERS] Alter or rename enum value

On 3/24/16 2:00 PM, Matthias Kurz wrote: ALTER TYPE bogon DROP VALUE 'cat'; -- not implemented in 9.5 but should work in future ROLLBACK; Dropping a value is significantly harder because that value could be in use. I'm certain there's a really good reason adding new values isn't allowed

Re: [HACKERS] Alter or rename enum value

> > ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > > > > > I was bored and thought "how hard could it be?", and a few hours' > > hacking later, I have something that seems to work. It doesn't do IF > > NOT EXISTS yet, and the error messaging could do with some improvement, > > and there

Re: [HACKERS] Alter or rename enum value

ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > > I was bored and thought "how hard could it be?", and a few hours' > hacking later, I have something that seems to work. It doesn't do IF > NOT EXISTS yet, and the error messaging could do with some improvement, > and there are no docs.

Re: [HACKERS] Alter or rename enum value

Matthias Kurz writes: [altering and dropping enum values] >>> Andrew Dunstan writes: >>> > On 03/09/2016 11:07 AM, Tom Lane wrote: >>> >> I have a vague recollection that we discussed this at the time the enum >>> >> stuff went in, and there are

Re: [HACKERS] Alter or rename enum value

On 9 March 2016 at 20:19, Matthias Kurz wrote: > Besides not being able to rename enum values there are two other > limitations regarding enums which would be nice to get finally fixed: > > 1) There is also no possibility to drop a value. > > 2) Quoting the docs ( >

Re: [HACKERS] Alter or rename enum value

Besides not being able to rename enum values there are two other limitations regarding enums which would be nice to get finally fixed: 1) There is also no possibility to drop a value. 2) Quoting the docs ( http://www.postgresql.org/docs/9.5/static/sql-altertype.html): "ALTER TYPE ... ADD VALUE

Re: [HACKERS] Alter or rename enum value

Andrew Dunstan writes: > On 03/09/2016 11:07 AM, Tom Lane wrote: >> I have a vague recollection that we discussed this at the time the enum >> stuff went in, and there are concurrency issues? Don't recall details >> though. > Rings a vague bell, but should it be any worse

Re: [HACKERS] Alter or rename enum value

On 03/09/2016 11:07 AM, Tom Lane wrote: Andrew Dunstan writes: On 03/09/2016 09:56 AM, Matthias Kurz wrote: Right now it is not possible to rename an enum value. Are there plans to implement this anytime soon? I don't know of any plans, but it would be a useful thing.

Re: [HACKERS] Alter or rename enum value

Andrew Dunstan writes: > On 03/09/2016 09:56 AM, Matthias Kurz wrote: >> Right now it is not possible to rename an enum value. >> Are there plans to implement this anytime soon? > I don't know of any plans, but it would be a useful thing. I agree it > wouldn't be too hard.

Re: [HACKERS] Alter or rename enum value

On 03/09/2016 09:56 AM, Matthias Kurz wrote: Hi! Right now it is not possible to rename an enum value. Are there plans to implement this anytime soon? I had a bit of a discussion on the IRC channel and it seems it shouldn't be that hard to implement this. Again, I am talking about renaming

[HACKERS] Alter or rename enum value

Hi! Right now it is not possible to rename an enum value. Are there plans to implement this anytime soon? I had a bit of a discussion on the IRC channel and it seems it shouldn't be that hard to implement this. Again, I am talking about renaming the values, not the enum itself. Thanks!