Re: REINDEX CONCURRENTLY 2.0

On 3/8/17 9:34 AM, Andreas Karlsson wrote:
>> Also, if by any chance you think (or use any
>> software that thinks) that OIDs for system objects are a stable
>> identifier, this will be the first case where that ceases to be true.
>> If the system is shut down or crashes or the session is killed, you'll
>> be left with stray objects with names that you've never typed into the
>> system.  I'm sure you're going to say "don't worry, none of that is
>> any big deal" and maybe you're right.
>
> Hm, I cannot think of any real life scenario where this will be an issue
> based on my personal experience with PostgreSQL, but if you can think of
> one please provide it. I will try to ponder some more on this myself.

The case I currently have is to allow tracking database objects similar 
to (but not the same) as how we track the objects that belong to an 
extension[1]. That currently depends on event triggers to keep names 
updated if they're changed, as well as making use of the reg* types. If 
an event trigger fired as part of the index rename (essentially treating 
it like an ALTER INDEX) then I should be able to work around that.

The ultimate reason for doing this is to provide something similar to 
extensions (create a bunch of database objects that are all bound 
together), but also similar to classes in OO languages (so you can have 
multiple instances).[2]

Admittedly, this is pretty off the beaten path and I certainly wouldn't 
hold up the patch because of it. I am hoping that it'd be fairly easy to 
fire an event trigger as if someone had just renamed the index.

1: https://github.com/decibel/object_reference
2: https://github.com/decibel/pg_classy
-- 
Jim Nasby, Chief Data Architect, OpenSCG
http://OpenSCG.com