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
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
In response to
pgsql-docs by date
|Next:||From: Bojidar Mihajlov||Date: 2004-11-30 13:56:21|
|Subject: Large objects through ODBS|
|Previous:||From: Tom Lane||Date: 2004-11-28 20:39:35|
|Subject: Re: Section 188.8.131.52, Regular Expression Matching Rules |
pgsql-patches by date
|Next:||From: Kris Jurka||Date: 2004-11-28 22:14:32|
|Subject: Re: [BUGS] solaris non gcc compiler debug options|
|Previous:||From: Bruce Momjian||Date: 2004-11-28 03:33:12|
|Subject: Re: Cache last known per-tuple offsets to speed long tuple|