Justin Clift wrote:
Christopher Kings-Lynne wrote:
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 fin
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
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 figurin
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 an
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
Christopher Kings-Lynne wrote:
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
"information_sc
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 ti
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 peop
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
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 indi
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 to release and it would be nice to
be able to write code which is more future proof.
Really? It wi
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 specified in ISO/IEC
> 9075 o
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 prov
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
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 f
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
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)---
T
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 i
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
Greg Sabino Mullane wrote:
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 conta
-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 St
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 liter
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 cou
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 broa
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
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
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
> >>> implementa
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 g
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
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
>>> informatio
> -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.co
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 inform
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*, no
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
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
i
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 broadcast)--
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
37 matches
Mail list logo
