Re: WIP -- renaming implicit sequences - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: WIP -- renaming implicit sequences
Date
Msg-id CADLWmXVTJDEbqMqyGr5LLZbkxgRQJUAKP9EUwpx53+kaYHVJzA@mail.gmail.com
Whole thread Raw
In response to Re: WIP -- renaming implicit sequences  (Robert Haas <robertmhaas@gmail.com>)
List 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!


pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: [v9.2] sepgsql's DROP Permission checks
Next
From: Ants Aasma
Date:
Subject: Re: Re: Add minor version to v3 protocol to allow changes without breaking backwards compatibility