Re: WIP -- renaming implicit sequences
Thomas Munro <munro@ip9.org>
From: Thomas Munro <munro@ip9.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2012-01-21T10:14:47Z
Lists: pgsql-hackers
On 19/01/2012, Robert Haas <robertmhaas@gmail.com> wrote: > rhaas=# alter sequence foo_a_seq rename to bob; > ALTER SEQUENCE > > If somebody renames the table or the column at this point, it's a good > bet that they *don't* want bob renamed. FWIW the patch addresses this case and wouldn't try to rename 'bob'. > Another, admittedly minor consideration is that this can introduce > some subtle concurrency bugs that we don't have today. For example, > suppose we choose a new name for the sequence which isn't in use, but > then between the time when we pick the name and the time we do the > insert the name becomes used, due to some concurrent transaction. Now > we'll fail with a rather baffling error message. That isn't > necessarily a huge problem - we have lots of code that is prone to > such race conditions - but it's not wonderful either. ... I thought about this, and it seemed to me that (1) the same race already applies when you CREATE a table with a serial column and (2) anyone running a bunch of DDL concurrently with other DDL operations already needs to coordinate their action or deal with occasional name collisions in general. But yeah I see that it's not ideal. > I think we should remove this from the TODO list, or at least document > that there are a number of reasons why it might be a deeper hole than > it appears to be at first glance. Fair enough, I'll leave it there. Thanks for the feedback!