information schema table names in 8.0.0

[Ed L.]

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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Ed L.]

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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Alvaro Herrera]

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)
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Stephan Szabo]

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.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)