Thread: information_schema OID

As information_schema has found its way into the initdb script, it can 
be considered a system schema. Unfortunately, it has an arbitrary OID, 
so pgadmin3 will not detect it as system schema.
How should pgadmin3 handle this? Will information_schema eventually get 
a dedicated OID or should we check for the name?

Regards,

Andreas

> As information_schema has found its way into the initdb script, it can
> be considered a system schema. Unfortunately, it has an arbitrary OID,
> so pgadmin3 will not detect it as system schema.
> How should pgadmin3 handle this? Will information_schema eventually get
> a dedicated OID or should we check for the name?

Also, should the information_schema be pinned so that it cannot be dropped?
This would help db admin projects such as phpPgAdmin be able to rely on
information_schema being there...

Chris

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Also, should the information_schema be pinned so that it cannot be dropped?

Why?  Sure, the DBA had better be damn certain that he wants to do that
before he does it.  But we let superusers drop lots of things that they
would be better advised not to.  If someone wants a small disk footprint
I can imagine a good case for feeling that information_schema is useless.

> This would help db admin projects such as phpPgAdmin be able to rely on
> information_schema being there...

Rely away.  It's not your business to work in databases that a superuser
has made arbitrary changes to.  Do you claim to still work if he renames
the integer "=" operator to "!#&@!!" ?
        regards, tom lane

Andreas Pflug writes:

> How should pgadmin3 handle this? Will information_schema eventually get
> a dedicated OID or should we check for the name?

Check the name, as you should for all system objects.

-- 
Peter Eisentraut   peter_e@gmx.net