Thread: information schema table names in 8.0.0

I see that a newly created database in 8.0.0beta2 now has tables sql_sizing,
sql_sizing_profiles, sql_packages, sql_features, sql_implementation_info,
and sql_languages as part of the information schema.

Given these are system tables, why are these tables not prefixed with 'pg_',
as in 'pg_sql_sizing', etc?

Ed

On Wednesday September 8 2004 1:50, Ed L. wrote:
> I see that a newly created database in 8.0.0beta2 now has tables
> sql_sizing, sql_sizing_profiles, sql_packages, sql_features,
> sql_implementation_info, and sql_languages as part of the information
> schema.
>
> Given these are system tables, why are these tables not prefixed with
> 'pg_', as in 'pg_sql_sizing', etc?

For years we have long used the fact that pgsql system tables are prefixed
with 'pg_' in various DBA utilities (e.g., dampen noise when querying
pg_tables/pg_class), and more recently to auto-initialize replication for
user tables only.  Changing that convention breaks our stuff.  I realize
this information schema horse left the barn a year ago, I'm only now seeing
it as we skipped 7.4 altogether.  Just curious if there is good reason for
the change in convention, so as to ease my pain.

Ed

On Wed, Sep 08, 2004 at 02:02:54PM -0600, Ed L. wrote:
> On Wednesday September 8 2004 1:50, Ed L. wrote:
> > I see that a newly created database in 8.0.0beta2 now has tables
> > sql_sizing, sql_sizing_profiles, sql_packages, sql_features,
> > sql_implementation_info, and sql_languages as part of the information
> > schema.
> >
> > Given these are system tables, why are these tables not prefixed with
> > 'pg_', as in 'pg_sql_sizing', etc?
>
> For years we have long used the fact that pgsql system tables are prefixed
> with 'pg_' in various DBA utilities (e.g., dampen noise when querying
> pg_tables/pg_class), and more recently to auto-initialize replication for
> user tables only.  Changing that convention breaks our stuff.  I realize
> this information schema horse left the barn a year ago, I'm only now seeing
> it as we skipped 7.4 altogether.  Just curious if there is good reason for
> the change in convention, so as to ease my pain.

The names are defined in the SQL standard, so they are not really open
for debate.

What you should use to filter out system objects from listings is schema
names.  Anything in the pg_catalog and information_schema schemas can be
filtered out.  In fact, that's what psql does now.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat)

On Wed, 8 Sep 2004, Ed L. wrote:

> On Wednesday September 8 2004 1:50, Ed L. wrote:
> > I see that a newly created database in 8.0.0beta2 now has tables
> > sql_sizing, sql_sizing_profiles, sql_packages, sql_features,
> > sql_implementation_info, and sql_languages as part of the information
> > schema.
> >
> > Given these are system tables, why are these tables not prefixed with
> > 'pg_', as in 'pg_sql_sizing', etc?
>
> For years we have long used the fact that pgsql system tables are prefixed
> with 'pg_' in various DBA utilities (e.g., dampen noise when querying
> pg_tables/pg_class), and more recently to auto-initialize replication for
> user tables only.  Changing that convention breaks our stuff.  I realize
> this information schema horse left the barn a year ago, I'm only now seeing
> it as we skipped 7.4 altogether.  Just curious if there is good reason for
> the change in convention, so as to ease my pain.

INFORMATION_SCHEMA and its contents are part of the SQL spec.