Thread: Extending System Views: proposal for 8.1/8.2

Extending System Views: proposal for 8.1/8.2

From
Josh Berkus
Date:
Folks,

This is for 8.1, or for 8.2 if we have a no-initdb cycle for 8.1.  

I'm proposing to expand both the coverage and number of "system views".  Our
system views are an extremely useful way to get data about the system if
you're not on PSQL.   They are a better idea than using the underlying system
tables, both becuase the system table output can be kind of cryptic, and
because the system tables may change but it will be easy to maintain the
views the same.

Therefore, I want to run my proposed design past the team, because I'd like to
build system views we can live with for the next 3-4 versions, which will
allow GUI and library builders to have a reliable, static interface onto the
system objects.  Suggestions & adjustments, please!   It shouldn't take me
long to write these with a clear spec.

(oh, and information_schema really doesn't cover this because the SQL spec is
rather limited in what objects it describes)

pg_tables
        ADD comment

pg_stats
        ADD statstarget for each column
        (the SET STATISTICS for each column)

pg_user
        ADD groups (array)

pg_functions --> create new view
        schemaname
        functionname
        functionowner
        parameters (array)
        returntype
        functionsettings  (things like STABLE)
        functionsource
        comment

pg_views
        ADD comment

pg_columns --> new view **
        schemaname
        tablename
        columnname
        datatype
        typemodifiers (NOT NULL, default, etc)
        comment

pg_aggregates --> new view **
        schemaname
        aggregatename
        aggregateowner
        datatype
        initvalue
        transfunction
        finalfunction
        comment
        
pg_operators --> new view **
        schemaname
        operatorname
        operatorowner
        operatortype
        datatypes (array)
        operatorfunction
        comment

pg_schemas --> new view
        schemaname
        schemaowner
        defaulttablespace
        comment

pg_triggers --> new view ***
        schemaname
        tablename
        triggername
        triggerowner
        triggerfunction
        conditions (update, insert, etc.)
        modifiers (deferrable, etc.)
        enabled
        comment

pg_foriegnkeys --> new view ****
        parentschema
        parenttable
        parentcolumns (array)
        childschema
        childtable
        childcolumns (array)

Views I think will be wanted by I've not really figured out how to define yet:
pg_types
pg_domains
pg_constraints
pg_groups

NOTES & QUESTIONS:

** = for these three views, there are an enourmous number of system
aggregates, operators, etc.   I'm wondering if I should hide the system ones,
or simply trust the user to filter by schema?

*** = since there will be a seperate FK view, pg_triggers will omit FK
constrainttriggers.

**** = I've used the non-canon terms "parent" and "child" here.   The problem
is that the standard terms are completely confusing and unintuitive, such as
"referring" and "referenced".     Other suggestions are welcome.

So, feedback before I start writing SQL?        

Oh, also what file are the system views defined in?


--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Re: Extending System Views: proposal for 8.1/8.2

From
David Fetter
Date:
On Fri, Jan 21, 2005 at 12:17:08PM -0800, Josh Berkus wrote:
> Folks,
> 
> This is for 8.1, or for 8.2 if we have a no-initdb cycle for 8.1.  
> 
> I'm proposing to expand both the coverage and number of "system views".  Our 
> system views are an extremely useful way to get data about the system if 
> you're not on PSQL.   They are a better idea than using the underlying system 
> tables, both becuase the system table output can be kind of cryptic, and 
> because the system tables may change but it will be easy to maintain the 
> views the same.
> 
> Therefore, I want to run my proposed design past the team, because I'd like to 
> build system views we can live with for the next 3-4 versions, which will 
> allow GUI and library builders to have a reliable, static interface onto the 
> system objects.  Suggestions & adjustments, please!   It shouldn't take me 
> long to write these with a clear spec.
> 
> (oh, and information_schema really doesn't cover this because the SQL spec is 
> rather limited in what objects it describes)
> 
> pg_tables
>         ADD comment
> 
> pg_stats
>         ADD statstarget for each column
>         (the SET STATISTICS for each column)
> 
> pg_user
>         ADD groups (array)
> 
> pg_functions --> create new view
>         schemaname
>         functionname
>         functionowner
>         parameters (array)
>         returntype
>         functionsettings  (things like STABLE)
>         functionsource
>         comment
> 
> pg_views
>         ADD comment
> 
> pg_columns --> new view **
>         schemaname
>         tablename
>         columnname
>         datatype
>         typemodifiers (NOT NULL, default, etc)
>         comment
> 
> pg_aggregates --> new view **
>         schemaname
>         aggregatename
>         aggregateowner
>         datatype
>         initvalue
>         transfunction
>         finalfunction
>         comment
>         
> pg_operators --> new view **
>         schemaname
>         operatorname
>         operatorowner
>         operatortype
>         datatypes (array)
>         operatorfunction
>         comment
> 
> pg_schemas --> new view
>         schemaname
>         schemaowner
>         defaulttablespace
>         comment
> 
> pg_triggers --> new view ***
>         schemaname
>         tablename
>         triggername
>         triggerowner
>         triggerfunction
>         conditions (update, insert, etc.)
>         modifiers (deferrable, etc.)
>         enabled
>         comment
> 
> pg_foriegnkeys --> new view ****
>         parentschema
>         parenttable
>         parentcolumns (array)
>         childschema
>         childtable
>         childcolumns (array)
> 
> Views I think will be wanted by I've not really figured out how to define yet:
> pg_types
> pg_domains
> pg_constraints
> pg_groups

I don't know how this fits in, but it would be *very* nice to have
SQLSTATE meta-information available via SQL.  I've sent in a patch for
this.

Cheers,
D
-- 
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!


Re: Extending System Views: proposal for 8.1/8.2

From
"Jim C. Nasby"
Date:
I'm glad to see a types view. A while ago I was trying to figure out a
way to query the pg_* views to see if a particular function existed. I
quickly got stuck trying to figure out how to properly handle the
arguments array. The solution Tom gave in this case was just to
hard-code the OID for the type I needed. It works, but it seems rather
ugly.

I think it would be good if pg_function included an array of parameter
types of the standard parameter names, as well as the type OIDs.

On Fri, Jan 21, 2005 at 12:17:08PM -0800, Josh Berkus wrote:
> ** = for these three views, there are an enourmous number of system 
> aggregates, operators, etc. ? I'm wondering if I should hide the system ones, 
> or simply trust the user to filter by schema?

I think it would be handy to have a set of views defined that shows
everything, and have the 'normal set' (ie, the views with the easiest
name to type in) defined to hide the system stuff. I suspect that most
of the time people are using these views they don't care about the
system stuff.

> *** = since there will be a seperate FK view, pg_triggers will omit FK 
> constrainttriggers.
I think it would be useful if there was a version of the view that
showed what these triggers were. If you want to see all the triggers
operating on a table, for example.

I guess this is a bit of a grey area, since I don't know of any other
database that handles RI using triggers.

> **** = I've used the non-canon terms "parent" and "child" here. ? The problem 
> is that the standard terms are completely confusing and unintuitive, such as 
> "referring" and "referenced". ? ? Other suggestions are welcome.

I think parent and child is fine.

On another naming note; the naming convention for system stuff has
always driven me nuts. Some the letter prefix (ie: tab for tables) in
front of every field name, with no underscores or anything. Extensive
use of abbreviations that you need to remember (ie: indnatts, indexprs,
indpred). No use of underscores (indisunique). Yet the view and table
names do use underscores.

I realize that there's probably a pretty tight mapping between catalog
*tables* and internals and that changing anything there would probably
have a huge impact on code. Of course there's also existing code that
uses the pg_catalog stuff that's defined today.

What I'm hoping is that with the amount of work involved in the changes
Josh is suggesting, instituting a more rational naming scheme wouldn't
be that much extra effort, at least for things that are being added. One
possibility might be to leave the existing views alone (and possibly
deprecate them), and just create new views. What I'd like to see is
names that are spelled out and underscore delimited.

BTW, this is something I can actually work on myself, and I'd be happy
to work on the code as consensus is reached on what the different views
should look like.

My $2.00.
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


Re: Extending System Views: proposal for 8.1/8.2

From
Neil Conway
Date:
Jim C. Nasby wrote:
> On another naming note; the naming convention for system stuff has
> always driven me nuts. Some the letter prefix (ie: tab for tables) in
> front of every field name, with no underscores or anything. Extensive
> use of abbreviations that you need to remember (ie: indnatts, indexprs,
> indpred). No use of underscores (indisunique). Yet the view and table
> names do use underscores.

I agree the naming conventions for system catalog columns is less than 
optimal, but it seems a net loss to rename columns that already exist 
(given the amount of code that would need to be updated, both within the 
tree and in admin utilities and the like). Renaming all the system 
catalogs and providing backward compatibility views would mean you'd 
only need to modify the PG source, although of course those 
modifications would be pretty time-consuming...

In any case, that's no reason not to try for better names in newly-added 
system objects.

-Neil


Re: Extending System Views: proposal for 8.1/8.2

From
Troels Arvin
Date:
On Fri, 21 Jan 2005 12:17:08 -0800, Josh Berkus wrote:

> I'm proposing to expand both the coverage and number of "system views".

Generally: Nice. But have you considered if the INFORMATION_SCHEMA could
be used? Unfortunately, the INFORMATION_SCHEMA currently has a major
problem in its usefulness in PostgreSQL:
http://troels.arvin.dk/db/rdbms/#cli-list_of_tables-postgresql-gotchas

However, that could (and in my opinion: _should_) be fixed be enforcing
schema-wide constraint identifier uniqueness.

> pg_stats
>         ADD statstarget for each column
>         (the SET STATISTICS for each column)

This reminds me: It would be nice if it were somehow possible to determine
when (if ever) statistics have been gathered for a given schema object.
This needs changes to more than VIEWs, though.

> pg_columns --> new view **
>         schemaname
>         tablename
>         columnname
>         datatype
>         typemodifiers (NOT NULL, default, etc)
>         comment

Do you propose that typemodifiers be one column? - If would prefer if it
were several columns. And it would be useful if it were easy to determine
if a column is- solely - or part of - a uniqueness constraint- solely - or part of - a foreign key (pointing where?)-
ifit is subject to a (set of) CHECK constraints
 

I could use this to more easily build user interfaces (forms).

-- 
Greetings from Troels Arvin, Copenhagen, Denmark




Re: Extending System Views: proposal for 8.1/8.2

From
"Jim C. Nasby"
Date:
On Sat, Jan 22, 2005 at 08:46:21PM +1100, Neil Conway wrote:
> Jim C. Nasby wrote:
> >On another naming note; the naming convention for system stuff has
> >always driven me nuts. Some the letter prefix (ie: tab for tables) in
> >front of every field name, with no underscores or anything. Extensive
> >use of abbreviations that you need to remember (ie: indnatts, indexprs,
> >indpred). No use of underscores (indisunique). Yet the view and table
> >names do use underscores.
> 
> I agree the naming conventions for system catalog columns is less than 
> optimal, but it seems a net loss to rename columns that already exist 
> (given the amount of code that would need to be updated, both within the 
> tree and in admin utilities and the like). Renaming all the system 
> catalogs and providing backward compatibility views would mean you'd 
> only need to modify the PG source, although of course those 
> modifications would be pretty time-consuming...
> 
> In any case, that's no reason not to try for better names in newly-added 
> system objects.

Just to be clear, I'm not suggesting renaming anything in any of the
existing pg_catalog objects. I'm suggesting creating a new, easier to
use set of views that would sit on top of pg_catalog.
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


Re: Extending System Views: proposal for 8.1/8.2

From
"Josh Berkus"
Date:
Jim,

> Just to be clear, I'm not suggesting renaming anything in any of the
> existing pg_catalog objects. I'm suggesting creating a new, easier to
> use set of views that would sit on top of pg_catalog.

I have no objection to using easier to read names for the system views.(This is the user-friendly views, folks, not the
actualsystem
 
objects!).   The reason I suggested the names I did was to be
consistent.

Thing is, at least for the next version, if we are changing the naming
conventions, we need to leave the old views alone, at least for one
version (pg_tables, pg_views, etc.).  This means a new view name scheme
for the new views.  Suggestions?  

I might suggest simply "tables" "triggers" "types" etc.   The plurals
of these reserved words are no, AFAIK, reserved.  And if users are
creating identically named objects in public, they just need to
remember to use the schema.

Oh, also for the "Parameters (array)" etc.?   I was planning on having
text names there, *not* an array of OIDs or whatever.   The purpose of
these views is to be user-friendly.

--Josh


Re: Extending System Views: proposal for 8.1/8.2

From
Tom Lane
Date:
"Josh Berkus" <josh@agliodbs.com> writes:
> I might suggest simply "tables" "triggers" "types" etc.   The plurals
> of these reserved words are no, AFAIK, reserved.  And if users are
> creating identically named objects in public, they just need to
> remember to use the schema.

Only if you put them in some other schema.  We have specifically
promised not to create any tables/views in pg_catalog that do not
have names beginning with "pg_" --- see
http://developer.postgresql.org/docs/postgres/ddl-schemas.html#DDL-SCHEMAS-CATALOG
        regards, tom lane


Re: Extending System Views: proposal for 8.1/8.2

From
"Jim C. Nasby"
Date:
On Sat, Jan 22, 2005 at 01:36:54PM -0800, Josh Berkus wrote:
> Jim,
> 
> > Just to be clear, I'm not suggesting renaming anything in any of the
> > existing pg_catalog objects. I'm suggesting creating a new, easier to
> > use set of views that would sit on top of pg_catalog.
> 
> I have no objection to using easier to read names for the system views.
>  (This is the user-friendly views, folks, not the actual system
> objects!).   The reason I suggested the names I did was to be
> consistent.

Out of curiosity, what's the relation between the tables in pg_catalog
and the 'actual system objects'? I ass-u-me'd that these tables were the
backing store for the real information, but maybe that's not the case.

> Thing is, at least for the next version, if we are changing the naming
> conventions, we need to leave the old views alone, at least for one
> version (pg_tables, pg_views, etc.).  This means a new view name scheme
> for the new views.  Suggestions?  

If we're dropping the pg_, maybe call the new schema just 'catalog'?

> I might suggest simply "tables" "triggers" "types" etc.   The plurals
> of these reserved words are no, AFAIK, reserved.  And if users are
> creating identically named objects in public, they just need to
> remember to use the schema.

Actually, the view names don't bother me at all. Granted, pg_ is 3 extra
characters to type, but the names are crystal clear. What I don't like
are the field names inside the views, and especially inside the
pg_catalog tables.

> Oh, also for the "Parameters (array)" etc.?   I was planning on having
> text names there, *not* an array of OIDs or whatever.   The purpose of
> these views is to be user-friendly.

I think these views are also very useful in certain programming
situations, in which also having the OIDs might be very useful. Another
option would be to have functions that given a array of names would
return a array of OIDs.
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


Re: Extending System Views: proposal for 8.1/8.2

From
lsunley@mb.sympatico.ca
Date:
In <20050122232132.GS67721@decibel.org>, on 01/22/05   at 05:21 PM, "Jim C. Nasby" <decibel@decibel.org> said:

>On Sat, Jan 22, 2005 at 01:36:54PM -0800, Josh Berkus wrote: > Jim,
>> 
>> > Just to be clear, I'm not suggesting renaming anything in any of the
>> > existing pg_catalog objects. I'm suggesting creating a new, easier to
>> > use set of views that would sit on top of pg_catalog.
>> 
>> I have no objection to using easier to read names for the system views.
>>  (This is the user-friendly views, folks, not the actual system
>> objects!).   The reason I suggested the names I did was to be
>> consistent.

>Out of curiosity, what's the relation between the tables in pg_catalog
>and the 'actual system objects'? I ass-u-me'd that these tables were the
>backing store for the real information, but maybe that's not the case.

>> Thing is, at least for the next version, if we are changing the naming
>> conventions, we need to leave the old views alone, at least for one
>> version (pg_tables, pg_views, etc.).  This means a new view name scheme
>> for the new views.  Suggestions?  

>If we're dropping the pg_, maybe call the new schema just 'catalog'?

That will break all of the older ODBC drivers.


-- 
-----------------------------------------------------------
lsunley@mb.sympatico.ca
-----------------------------------------------------------



Re: Extending System Views: proposal for 8.1/8.2

From
Alvaro Herrera
Date:
On Sat, Jan 22, 2005 at 05:21:32PM -0600, Jim C. Nasby wrote:

> Out of curiosity, what's the relation between the tables in pg_catalog
> and the 'actual system objects'? I ass-u-me'd that these tables were the
> backing store for the real information, but maybe that's not the case.

They are.


> I think these views are also very useful in certain programming
> situations, in which also having the OIDs might be very useful. Another
> option would be to have functions that given a array of names would
> return a array of OIDs.

So why not have both in the view?  It's not like you are storing
duplicated data anyway.

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Ellos andaban todos desnudos como su madre los parió, y también las mujeres,
aunque no vi más que una, harto moza, y todos los que yo vi eran todos
mancebos, que ninguno vi de edad de más de XXX años" (Cristóbal Colón)


Re: Extending System Views: proposal for 8.1/8.2

From
Tom Lane
Date:
"Jim C. Nasby" <decibel@decibel.org> writes:
> If we're dropping the pg_, maybe call the new schema just 'catalog'?

Any new schemas introduced by PG itself will be named pg_something.
This is not open to negotiation --- it's what we've promised to users
to avoid tromping on their schema namespace.
        regards, tom lane


Re: Extending System Views: proposal for 8.1/8.2

From
Josh Berkus
Date:
Tom,

> Any new schemas introduced by PG itself will be named pg_something.
> This is not open to negotiation --- it's what we've promised to users
> to avoid tromping on their schema namespace.

I can see the sense in that.  So, there's four ways I can see to do things:

1) leave the existing views (pg_tables, pg_views, etc.) the way they are 
except for adding columns.   Create new views based on the naming scheme of 
the old.

2) create new views in pg_catalog, using new names.  The problem with this is 
that the most intuitive names (pg_tables, pg_views) are taken by the old 
views and I'm not sure what to name the new ones.

3) create a new schema with the system views in it, called for example 
pg_system_views.   This seems cluttered to me; a whole new schema just for a 
dozen views?  

4) ignore backwards compatibility and just re-write the old views.   I can 
hear the shouting already ...

So, a choice of annoying options.   Does anyone else on the channel have 
opinions?

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


Re: Extending System Views: proposal for 8.1/8.2

From
"Marc G. Fournier"
Date:
I may be missing something here, but haven't we always stated that 
using 'SELECT *' should be frown'd upon for the most part? Is there a 
reason why adding a column/field to an existing view should be considered 
a bad thing?

As long as we don't remove existing colums that an app could be using, but 
only adding a column, there shouldn't be any issues with backwards 
compatibility, shoudl there?

On Sun, 23 Jan 2005, Josh Berkus wrote:

> Tom,
>
>> Any new schemas introduced by PG itself will be named pg_something.
>> This is not open to negotiation --- it's what we've promised to users
>> to avoid tromping on their schema namespace.
>
> I can see the sense in that.  So, there's four ways I can see to do things:
>
> 1) leave the existing views (pg_tables, pg_views, etc.) the way they are
> except for adding columns.   Create new views based on the naming scheme of
> the old.
>
> 2) create new views in pg_catalog, using new names.  The problem with this is
> that the most intuitive names (pg_tables, pg_views) are taken by the old
> views and I'm not sure what to name the new ones.
>
> 3) create a new schema with the system views in it, called for example
> pg_system_views.   This seems cluttered to me; a whole new schema just for a
> dozen views?
>
> 4) ignore backwards compatibility and just re-write the old views.   I can
> hear the shouting already ...
>
> So, a choice of annoying options.   Does anyone else on the channel have
> opinions?
>
> -- 
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: Extending System Views: proposal for 8.1/8.2

From
Yann Michel
Date:
Hi,

On Sun, Jan 23, 2005 at 12:16:31PM -0800, Josh Berkus wrote:
> 
> 4) ignore backwards compatibility and just re-write the old views.   I can 
> hear the shouting already ...
> 
> So, a choice of annoying options.   Does anyone else on the channel have 
> opinions?

Isn't it a usefull option to introduce a postgresql-conf parameter to
set the pg-views version? I mean, in a pg 7.x-comaptibility-mode you
would only see the known views with their old content. If you set it to
8.x, you will see the new versions. So developers will get more time to
change their applications from the old views to the new ones while being
able to use new features.

Regards,
Yann


Re: Extending System Views: proposal for 8.1/8.2

From
"Jim C. Nasby"
Date:
I'm going to reply to 3 emails in one here...

Out of Josh's 4 options, I think a new schema makes the most sense.
Start with a clean plate. Yes, we'll end up with an ugly schema name,
but after the exiting pg_catalog is removed in a few versions, we can go
back to pg_catalog.

The idea of using a GUC to control which version of the schema you get
is also very interesting, though I don't know how workable it is. It
does have a downside, though... if you have a bunch of code that's using
pg_catalog, you'd have no choice but to migrate all of it at once. If
you have both the old and new versions of these tables/views present at
the same time then you can slowly migrate that code over.

Only adding columns to the existing views/tables is also an interesting
possibility. One issue is that it probably wouldn't work very well for
the tables in pg_catalog, though I guess SELECT rules could be written
to handle those. The other issue is that while SELECT * in code is
almost always a bad idea, SELECT * is human-friendly. I suspect that
basically every field in the existing tables/views will be renamed,
which means SELECT * in psql will now give you 2x the number of columns
you need. Though, this could be avoided by having a seperate set of
'human-readable' views. Having a seperate set of human-readable views
would also mean we could provide more human-friendly formatting in one
version, while the other version has everything you'd need to make it
the most useful from a programatic standpoint. An example that comes to
mind is the earlier discussion about function parameters. In a
human-readable version of pg_function, you'd probably just want
schema_name, function_name, parameters[], and return_type, where both
parameters[] and return_type would be the name of the types. But if
you're looking at functions programatically, it would be good to also
have parameter_oids[] and return_type_oid.

Personally, I'm leaning towards option 3: add new fields to pg_catalog.*
to support the new naming convention and new features, and add pg_human.
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


Re: Extending System Views: proposal for 8.1/8.2

From
Tom Lane
Date:
"Jim C. Nasby" <decibel@decibel.org> writes:
> Start with a clean plate. Yes, we'll end up with an ugly schema name,
> but after the exiting pg_catalog is removed in a few versions, we can go
> back to pg_catalog.

Huh?  pg_catalog isn't going away, and none of this discussion has
anything to do with changing the system catalogs themselves.  In any
case, creating these views with the idea that we will change their
locations later is a nonstarter.  People are going to be putting
the fully qualified paths into their applications.

> The idea of using a GUC to control which version of the schema you get
> is also very interesting, though I don't know how workable it is.

It could be spelled "schema_path" ... otherwise I don't see any way to
do it.  But I'm not sure it helps any to make two separate schemas.
Most admin-type apps wouldn't want to depend on the value of schema_path
(psql sure wouldn't, for instance) so they'd still have to change if
only to nail down the schema they want in each query.
        regards, tom lane


Re: Extending System Views: proposal for 8.1/8.2

From
Peter Eisentraut
Date:
Marc G. Fournier wrote:
> I may be missing something here, but haven't we always stated that
> using 'SELECT *' should be frown'd upon for the most part?

No, we have never stated that.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Re: Extending System Views: proposal for 8.1/8.2

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Marc G. Fournier wrote:
>> I may be missing something here, but haven't we always stated that
>> using 'SELECT *' should be frown'd upon for the most part?

> No, we have never stated that.

We do however point out in the docs that SELECT * is vulnerable to
addition of columns, eg footnote 1 here:
http://www.postgresql.org/docs/8.0/static/tutorial-select.html

We've always felt free to add columns to system catalogs at need,
and I don't see that adding some to system views is worse.
        regards, tom lane