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. 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
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.
Jim Nasby, Chief Data Architect, OpenSCG
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: