Message-ID: <40E8D70B.8010403@telstra.net>
Date: Mon, 05 Jul 2004 14:20:27 +1000
From: Justin Clift <jc@telstra.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20040406
MIME-Version: 1.0
To: Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Cc: PostgreSQL Hackers Mailing List <pgsql-hackers@postgresql.org>
Subject: Re: Adding column comment to information_schema.columns
References: <40E37E3F.2050400@telstra.net> <22066.1088656403@sss.pgh.pa.us>	
	<40E3949F.6020201@telstra.net>
	<40E3BB25.4020804@pse-consulting.de>	
	<k6xn3cph.fsf@bullysports.com>
	<40E4C305.4070309@familyhealth.com.au>	
	<40E4C367.2080303@telstra.net>
	<1088769438.15415.1.camel@fuji.krosing.net>
	<40E5716D.70403@familyhealth.com.au> <40E8C27E.2050505@telstra.net>
	<40E8C6CE.80405@familyhealth.com.au> <40E8D1D2.3000307@telstra.net>
	<40E8D572.1090205@familyhealth.com.au>
In-Reply-To: <40E8D572.1090205@familyhealth.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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
> 
> 
>