Timothy Dyck <Timothy_Dyck@zd.com> writes:
> Here's a list of things about PostgreSQL I had problems with:
> 1. "Null" is not accepted keyword on "create table" ("not null" is ok)
AFAICT from the SQL92 spec, NULL is not a legal column constraint.
I know some DBMSs accept it anyway, but we don't because it creates
grammatical ambiguities.
> 2. copy command 'with null as' option not functional
It looks like this has been added for 7.0 ... I haven't tried it
but I see the syntax is there.
> 3. try to create an index on a numeric and "no operator class for
> 'numeric' data type" error message results. Numerics not indexable?
Oversight in 6.5.* ... fixed for 7.0.
> 4. no outer join -- I had to drop one query because of this
Thomas is working on outer joins, but I'm not sure if it'll be ready
for 7.0. 7.1 for sure though; this is our most-requested missing SQL92
feature.
> 5. no alter table add constraint
Not there yet (but Peter E. was working on it when last seen...)
> 6. select count(distinct *) from a view gives a parser error on distinct
> -- distinct keyword not supported here?
No, but it is for 7.0.
> 7. one query (dss_select_05) has an avg on a numeric field. I got an
> overflow error (is there a cast to a longer type?). When the avg on
> numeric field is removed, the query consumes memory rapidly and doesn't
> terminate. I dropped this query.
Bug. I posted a patch for this and a couple of other NUMERIC problems
a few weeks ago; it'll be in 7.0 of course, and you can get the patch
off the pgsql-patches list archives if you need it to work in 6.5.*.
> 8. Can't start postmaster with more than 65536 buffers as I get a "FATAL
> 1: couldn't initialize shared buffer pool Hash Tbl". Variable overflow?
Probably. Hadn't occurred to me that we need to check for a sane upper
bound on the number of buffers, but I guess we do. (You do realize that
would be half a gig of in-memory buffers, right? If you've actually got
that much RAM, it's probably better to let the OS use it for general-
purpose disk buffers instead of dedicating it all to Postgres.)
> Also, is PostgreSQL 7 expected to be SQL-92 compliant? It's pretty close
> now.
We're getting closer all the time, but I wouldn't want to promise that
we'll ever have everything that's in SQL92.
Thanks for the report! I don't suppose you'd be interested in rerunning
your tests on current (pre-beta-7.0) sources?
regards, tom lane