pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: Matthias Kurz <m.kurz@irregular.at>
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 10:40:28 -0400
Message-ID: <56F69F5C.1060408@dunslane.net> (raw)
In-Reply-To: <3202.1459002341@sss.pgh.pa.us>
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>
	<56F6827F.9040104@dunslane.net>
	<3202.1459002341@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>



On 03/26/2016 10:25 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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 mutable set defined in another table --- it's called a foreign key.
> The point of inventing enums was to provide a lower-overhead solution
> for cases where the allowed value set is *not* mutable.  So okay, if we
> can allow certain cases of changing the value set without increasing
> the overhead, great.  But when we can't do it without adding a whole
> lot of complexity and overhead (and, no doubt, bugs), we need to just
> say no.
>
> Maybe the docs about enums need to be a little more explicit about
> pointing out this tradeoff.
>
> 			

OK, but we (in fact, you and I, for the most part) have provided a way 
to add new values. The trouble people have is the transaction 
restriction on that facility, because all the other changes they make 
with migration tools can be nicely wrapped in a transaction. And the 
thing is, in my recent experience on a project using quite a few enums, 
none of the transactions I'd like to include these mutations of enums in 
does anything that would be at all dangerous. It would be nice if we 
could find a less broad brush approach to dealing with the issue.

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



view thread (56+ messages)  latest in thread

Message-ID: <56F69F5C.1060408@dunslane.net>
Permalink:  ../56F69F5C.1060408@dunslane.net/
Also on:    postgresql.org/message-id/56F69F5C.1060408@dunslane.net

 · 

reply
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, tgl@sss.pgh.pa.us, david.g.johnston@gmail.com, m.kurz@irregular.at, Jim.Nasby@bluetreble.com
  Subject: Re: Alter or rename enum value
  In-Reply-To: <56F69F5C.1060408@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