[HACKERS] SQL99 feature list

2002-06-19 Thread Thomas Lockhart

I've just updated features.sgml to have a list of supported features
followed by a list of unsupported ones. There are some items in the
unsupported list which look easy to do. I've got patches for a MATCH
SIMPLE clause on referential integrity declarations, and am developing
patches for CREATE CAST, DROP CAST, and probably a few more items which
could be simple parser additions or changes. Look at

  http://developer.postgresql.org/docs/postgres/features.html

for the most recent version (it is not there yet but I'd expect it to be
there soon).

I'd like to look at supporting the various shorthand literal notations
like B'0101', X'ABCD', and N'national' in a better way in the lexer to
make sure that the information gets to the parser more robustly. Right
now, N'national' is not supported at all and the other two forms are
supported by transforming the input locally in the lexer which seems to
work but does not extend to the NATIONAL CHARACTER case. Comments and
suggestions are welcome.

Y'all may want to look at features.sgml to find projects if you are
looking for something to do; there are several items which look to be
relatively easy to accomplish and others at various levels of
difficulty...

- Thomas

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



[HACKERS] SQL99 feature list

2002-06-14 Thread Thomas Lockhart

As you probably know, SQL99 has dropped the rather useless
categorizations of basic, intermediate, and advanced SQL
compliance and instead lists a large number of labeled features. I've
put these into an appendix for the docs (not yet committed to cvs).

The list is organized as a (for now) three column table, with Feature,
Description, and Comment as the three column headers. This is a
relatively long list, covering several printed pages.

So, a question: should I list all features in the same table, with the
comment field indicating if something is not (yet) supported, or should
I split the features into two tables for supported and unsupported
features? The former keeps all of the information together if someone is
looking something up by feature, and the latter reduces the number of
required comments and makes it easier to see the complete list of
supported features.

- Thomas

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster