Christopher Kings-Lynne wrote:
>> There's a whole lot of difference between the skill level needed to
>> query the information_schema and find out things like table and column
>> names, vs looking into pg_namespace, pg_class and pg_attribute plus
>> understanding the specific info there to work out table and column names.
>>
>> I reckon that having information "pre-prepared" in views like those in
>> information_schema is "of course" going to be easier for people than
>> "raw" information our internal catalogs.
>>
>> Do you get where I'm coming from with this?
>
>
> Yes, but I disagree. Your opinion is as an experienced user anyway, and
> you're just putting words in novice mouths...
That I directly disagree with. I'm putting forth the viewpoint of the
people I work with here, who aren't PG experienced. They're Oracle
experienced.
> We've never had someone complain about querying stuff like that. For
> example, why do you need the comments on columns?
The "comment on columns" addition to the constraint_column_usage view
was a suggestion for our particular environment, where it's easier for
some of the Perl programmers to have one view that shows them all of the
needed info.
I'm not super caring either if we add this stuff or not to PG, it was
just a suggestion from the "trying to be helpful POV".
However, saying that people who aren't experienced with PG can easily
(i.e. time efficiently) figure out how to query table and column names
from PG by going through the pg_catalog stuff in comparison to things
like information_schema.* is just not right.
One other benefit of having more stuff in information_schema.* is that
the stuff there is "easier" to look at and figure out what it is. With
the view definitions that are provided to things like psql and pgAdmin
when people look at an information_schema view, it provides them a way
of figuring out where in the internal tables stuff is if they want to
look for it. i.e. they can find a column in
information_schema.constraint_column_usage and go "gee where is that in
the real PostgreSQL tables"? Then look at the code that generates it
and so on.
:)
Regards and best wishes,
Justin Clift
> Chris
>
>
>
