On 19/01/2012, Robert Haas <robertmhaas(at)gmail(dot)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!
In response to
pgsql-hackers by date
|Next:||From: Ants Aasma||Date: 2012-01-21 10:51:55|
|Subject: Re: Re: Add minor version to v3 protocol to allow changes
without breaking backwards compatibility|
|Previous:||From: Kohei KaiGai||Date: 2012-01-21 09:28:33|
|Subject: Re: [v9.2] sepgsql's DROP Permission checks|