From: Andrew Dunstan <andrew@dunslane.net>
To: David G. Johnston <david.g.johnston@gmail.com>
Cc: Matthias Kurz <m.kurz@irregular.at>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Alter or rename enum value
Date: Sat, 26 Mar 2016 08:37:19 -0400
Message-ID: <56F6827F.9040104@dunslane.net> (raw)
In-Reply-To: <CAKFQuwZeVdo=qQy-WV_hfqy0Wsit9tuhtZOLsq1Jx82eKc8bfQ@mail.gmail.com>
References: <CAO=2mx6uvgPaPDf-rHqG8=1MZnGyVDMQeh8zS4euRyyg4D35OQ@mail.gmail.com>
<56E049CC.8010201@dunslane.net>
<25605.1457539654@sss.pgh.pa.us>
<56E05635.70908@dunslane.net>
<28167.1457543612@sss.pgh.pa.us>
<CAO=2mx4rQHRvifT2yUQ1rz90A=9CVz4_Z0Sx1wTgwgQRzAimpQ@mail.gmail.com>
<CAO=2mx6rK_h4BC7y+3Nu-8fuZJXdFjd9FE_MZnzkH+vnMp0C-Q@mail.gmail.com>
<d8ja8ln7nl0.fsf@dalvik.ping.uio.no>
<d8j60wb7na4.fsf@dalvik.ping.uio.no>
<CAO=2mx6CgQXFJYXOpr4OJO+r8WX6PzEU5aT+K0vV94G7DxVJ0A@mail.gmail.com>
<56F49CF8.8050007@BlueTreble.com>
<27476.1458876456@sss.pgh.pa.us>
<CAO=2mx6EOh6uQQ57Kv2z0x=kuyVbkEbwiY8R2h6VCPL=Fxe5wg@mail.gmail.com>
<56F58876.6020508@dunslane.net>
<CAKFQuwZeVdo=qQy-WV_hfqy0Wsit9tuhtZOLsq1Jx82eKc8bfQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 03/26/2016 12:35 AM, David G. Johnston wrote:
> On Friday, March 25, 2016, Andrew Dunstan <andrew@dunslane.net
> <mailto:andrew@dunslane.net>> 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 do that safely. Enums pose
> special problems here exactly because unlike all other types the
> set of valid values is mutable.
>
>
> Yeah, I'm not sure there is much blue sky here as long as the
> definition of an enum is considered system data. It probably needs to
> be altered so that a user can create a table of class enum with a
> known layout that PostgreSQL can rely upon to perform optimizations
> and provide useful behaviors - at least internally. The most visible
> behavior being displaying the label while ordering using its position.
>
> The system, seeing a data type of that class, would have an implicit
> reference between columns of that type and the source table.
> You have to use normal cascade update/delete/do-nothing while
> performing DML on the source table.
>
> In some ways it would be a specialized composite type, and we could
> leverage that to you all the syntax available for those - but without
> having a different function for each differently named enum classed
> table since they all would share a common structure, differing only in
> name. But the tables would be in user space and not a preordained
> relation in pg_catalog. Maybe require they all inherit from some
> template but empty table...
>
>
We don't have the luxury of being able to redesign this as a green
fields development.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andrew@dunslane.net, david.g.johnston@gmail.com, m.kurz@irregular.at, tgl@sss.pgh.pa.us, Jim.Nasby@bluetreble.com
Subject: Re: Alter or rename enum value
In-Reply-To: <56F6827F.9040104@dunslane.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox