pg.ddx.io  pgsql-docs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Simon Riggs <simon@2ndquadrant.com>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Troels Arvin <troels@arvin.dk>
Cc: pgsql-patches@postgresql.org
Cc: pgsql-docs@postgresql.org
Subject: Re: [PATCHES] SQL conformance related patch
Date: Sun, 28 Nov 2004 21:35:25 +0000
Message-ID: <1101677725.2963.63.camel@localhost.localdomain> (raw)
In-Reply-To: <200411262334.16250.peter_e@gmx.net>
References: <1101381875.3068.27.camel@localhost>
	<1101498748.2870.78.camel@localhost.localdomain>
	<200411262334.16250.peter_e@gmx.net>

On Fri, 2004-11-26 at 22:34, Peter Eisentraut wrote:
> Simon Riggs wrote:
> > The sections Supported Features and Unsupported Features cover both
> > Mandatory (Core) and Optional features in the same section. It would
> > be better to separate these, just as the SQL standard itself does in
> > Annex F - SQL Feature Taxonomy.
> >

Please note that all that has been suggested is splitting a table into
two pieces, so that it matches the SQL:2003 standard's way of presenting
this information, as laid out in Annex F - SQL Feature Taxonomy. 

I found that arrangement useful in understanding the standard and wished
to recommend it to the project.

> > This seems especially important for the Unsupported Features section,
> > since the length of the list makes it look like 100% support is a
> > long way off, whereas it is only 14 features away, and many of them
> > minor [see Troels' low hanging fruit list on this thread]
> 
> If the "core" set of features were at all useful in practice then I 
> would think about this, but it is not, so we'd just end up arranging 
> the tables for marketing purposes instead of information purposes.  Ten 
> years ago this would have been equivalent to making a separate section 
> for SQL 92 Entry level and rejoicing upon completion, while realizing 
> that a real-life DBMS needs at least Intermediate level.

I agree completely with your assessment of SQL-92 Entry and Intermediate
level. Having recently spent an hour or two looking at the SQL:2003
standard, I don't think the analogy that SQL:2003 Core is similar to
SQL-92 Entry level is a useful one. I understand why people would think
this, because I would definitely have thought exactly the same, before I
looked.

For example, Microsoft SQL Server claims SQL-92 Entry level. If SQL:2003
were similar then they would simply switch the claim to SQL:2003 without
problem. They do not, because they cannot.

Please review what the list of SQL:2003 Core features contains:
SAVEPOINTS, outer joins, triggers, derived tables, quantified
sub-selects, constraints etc.. but not object-relational features, which
are only Optional. IMHO these features are useful in practice.

Yes, there are also many Optional features that are also desirable.

-- 
Best Regards, Simon Riggs




view thread (9+ messages)

Message-ID: <1101677725.2963.63.camel@localhost.localdomain>
Permalink:  ../1101677725.2963.63.camel@localhost.localdomain/
Also on:    postgresql.org/message-id/1101677725.2963.63.camel@localhost.localdomain

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-docs@postgresql.org
  Cc: simon@2ndquadrant.com, peter_e@gmx.net, troels@arvin.dk, pgsql-patches@postgresql.org
  Subject: Re: [PATCHES] SQL conformance related patch
  In-Reply-To: <1101677725.2963.63.camel@localhost.localdomain>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox