Justin Clift wrote:
Christopher Kings-Lynne wrote:
snip
Anyone who's writing queries that are examing the schema of the
database is by definition not a newbie...
By newbie here, I mean someone who's a PG newbie but has a
reasonable understanding of databases (i.e. Oracle, etc) would
generally
Christopher Kings-Lynne wrote:
Well, if we add them (and they would be very useful I reckon) should
we ensure there's an obvious PG naming thing happening?
Why are they useful If you want PG specific stuff then use the PG
specific catalogs!!!
My take on this is that it's a LOT easier for
My take on this is that it's a LOT easier for people who don't know the
internals of the PG catalogs to be able to query the information schema,
as in the information schema things are generally explicitly named.
Much easier for non-experts, which most people don't want to have to
invest the
Christopher Kings-Lynne wrote:
snip
Anyone who's writing queries that are examing the schema of the database
is by definition not a newbie...
By newbie here, I mean someone who's a PG newbie but has a reasonable
understanding of databases (i.e. Oracle, etc) would generally find the
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
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
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Do you get where I'm coming from with this?
Yes, but I disagree.
Same here. The portable information already is in information_schema,
and I don't really see that it's better to find unportable information
in information_schema views than in
I didn't write that (or at least, I didn't mean to write that :-). The
SQL standard tells that they will not use trailing underscores,
therefore *my* conclusion is that it is future proof (from a standards
perspective) if all PostgreSQL extensions use a trailing underscore.
Which also gives an
On Sat, Jul 03, 2004 at 18:02:01 +0800,
Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Why are they useful If you want PG specific stuff then use the PG
specific catalogs!!!
The information schema could be used to provide a more stable interface.
The pg catalog changes from release
On R, 2004-07-02 at 05:07, Justin Clift wrote:
Christopher Kings-Lynne wrote:
There is a huge difference between adhering to a standard and limiting
yourself to a standard. The real question is whether PostgreSQL's
goal is to support SQL standards, or whether PostgreSQL's goal is to
give
On Fri, 2004-07-02 at 07:57, Hannu Krosing wrote:
On R, 2004-07-02 at 05:07, Justin Clift wrote:
Christopher Kings-Lynne wrote:
There is a huge difference between adhering to a standard and limiting
yourself to a standard. The real question is whether PostgreSQL's
goal is to support
Well, if we add them (and they would be very useful I reckon) should we
ensure there's an obvious PG naming thing happening?
Why are they useful If you want PG specific stuff then use the PG
specific catalogs!!!
Chris
---(end of broadcast)---
On Fri, Jul 02, 2004 at 22:30:05 +0800,
Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Well, if we add them (and they would be very useful I reckon) should we
ensure there's an obvious PG naming thing happening?
Why are they useful If you want PG specific stuff then use the PG
Bruno Wolff III [EMAIL PROTECTED] writes:
Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Why are they useful If you want PG specific stuff then use the PG
specific catalogs!!!
The information schema could be used to provide a more stable interface.
The pg catalog changes from
On Fri, 02 Jul 2004 14:57:18 +0300, Hannu Krosing [EMAIL PROTECTED] wrote:
IIRC we were recently told (in this thread) that the SQL standard tells
to end local customisations with underscore, so it would be
'column_comment_'
I didn't write that (or at least, I didn't mean to write that :-).
On R, 2004-07-02 at 20:04, Tom Lane wrote:
Bruno Wolff III [EMAIL PROTECTED] writes:
Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Why are they useful If you want PG specific stuff then use the PG
specific catalogs!!!
The information schema could be used to provide a more
Jochem van Dieten [EMAIL PROTECTED] writes:
I didn't write that (or at least, I didn't mean to write that :-). The
SQL standard tells that they will not use trailing underscores,
Um ... actually that's not what it says:
NOTE 77 - It is the intention that no key word specified in ISO/IEC
9075
On Thu, 1 Jul 2004, Justin Clift wrote:
but we found it useful. It adds the column comments to the
information_schema.columns view.
Doesn't the specification say exactly what columns should exist?
Lots of things in the old system tables are not visible in the
information_schema because of
Not sure how worthwhile others will find this small patch (to CVS HEAD),
but we found it useful. It adds the column comments to the
information_schema.columns view.
Is column comment in the standard? If not, we cannot of course add it...
Chris
---(end of
Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
Not sure how worthwhile others will find this small patch (to CVS HEAD),
but we found it useful. It adds the column comments to the
information_schema.columns view.
This question has been touched on before, but I guess it's time to face
it
Justin Clift [EMAIL PROTECTED] writes:
Not sure how worthwhile others will find this small patch (to CVS HEAD),
but we found it useful. It adds the column comments to the
information_schema.columns view.
This question has been touched on before, but I guess it's time to face
it fair and
This question has been touched on before, but I guess it's time to face
it fair and square: is it reasonable for an SQL implementation to add
implementation-specific columns to an information_schema view? One
could certainly argue that the entire point of information_schema is
to be *standard*,
Justin Clift wrote:
Tom Lane wrote:
This question has been touched on before, but I guess it's time to face
it fair and square: is it reasonable for an SQL implementation to add
implementation-specific columns to an information_schema view? One
could certainly argue that the entire point of
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 01 July 2004 05:33
To: Justin Clift
Cc: PostgreSQL Hackers Mailing List
Subject: Re: [HACKERS] Adding column comment to
information_schema.columns
Justin Clift [EMAIL PROTECTED
Andreas Pflug [EMAIL PROTECTED] writes:
Justin Clift wrote:
Tom Lane wrote:
This question has been touched on before, but I guess it's time to
face it fair and square: is it reasonable for an SQL
implementation to add implementation-specific columns to an
information_schema view? One
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Thu, 1 Jul 2004 [EMAIL PROTECTED] wrote:
There is a huge difference between adhering to a standard and limiting
yourself to a standard.
Having pg specific system tables (as we do) is something we need of
course, for things that are not in the
On Thu, Jul 01, 2004 at 10:38:02 -0600,
[EMAIL PROTECTED] wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Yes, but if folks wanted to stick to the standard PostgreSQL would
still work. The only difference is that people who aren't concerned
about being more tied to PostgreSQL would get
On Thu, 1 Jul 2004 [EMAIL PROTECTED] wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Justin Clift wrote:
Tom Lane wrote:
This question has been touched on before, but I guess it's time to
face it fair and square: is it reasonable for an SQL
implementation to add
On Thu, 1 Jul 2004 [EMAIL PROTECTED] wrote:
We're advertising to do pure ANSI, so we'd mislead people if we
supplied non-standard columns.
Yes, but if folks wanted to stick to the standard PostgreSQL would
still work. The only difference is that people who aren't concerned
about being
On Thu, 1 Jul 2004 12:23:10 -0500, Bruno Wolff III [EMAIL PROTECTED] wrote:
Is there any provision in the information schema part of the standard for
vendor specific extensions?
Yes, there is:
An SQL-implementation may define objects that are associated with
INFORMATION_SCHEMA that
Jochem van Dieten wrote:
PS I think I spotted an inconsistency in the standard. It says to
tables that are defined in this Clause, while the Clause only
defines views, not tables.
Tables are base tables, views are derived tables, so this is OK.
---(end of
There is a huge difference between adhering to a standard and limiting
yourself to a standard. The real question is whether PostgreSQL's
goal is to support SQL standards, or whether PostgreSQL's goal is to
give PostgreSQL users a useful set of tools.
There are literally _hundreds_ of fields we
Christopher Kings-Lynne wrote:
There is a huge difference between adhering to a standard and limiting
yourself to a standard. The real question is whether PostgreSQL's
goal is to support SQL standards, or whether PostgreSQL's goal is to
give PostgreSQL users a useful set of tools.
There are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I agree. The stuff is certainly accessible in PG-specific tables, so
the argument that we are missing functionality doesn't hold any water
IMHO. The question is whether we have to keep information_schema
pristine. I think that you and
Greg Sabino Mullane wrote:
snip
If there is that much clamor for this, why not make a new schema,
such as pginformation_schema People could then tweak the views
to their heart's content, while keeping 100% compliance.
Doesn't sound very neat.
If we add a pginformation_schema, then it'd probably
Hi all,
Not sure how worthwhile others will find this small patch (to CVS HEAD),
but we found it useful. It adds the column comments to the
information_schema.columns view.
Hope it's useful.
:-)
Regards and best wishes,
Justin Clift
*** information_schema.sql.orig 2004-07-01 11:59:26.0
36 matches
Mail list logo
