Re: [SQL] COUNT(*) to find records which have a certain number of dependencies ? - Mailing list pgsql-patches

From Greg Stark
Subject Re: [SQL] COUNT(*) to find records which have a certain number of dependencies ?
Date
Msg-id 878yb3fst4.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: [SQL] COUNT(*) to find records which have a certain number of dependencies ?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Greg Stark <gsstark@mit.edu> writes:
> > This patch allows subqueries without aliases. This is SQL-non-spec-compliant
> > syntax that Oracle supports and many users expect to work.
>
> AFAIR you're the first to propose that we ignore the SQL spec here.
> When I wrote "see if anyone complains", I had in mind waiting for
> quite a few complaints before contemplating changing this...

I understand. But I expect there are lots of users this annoys. It's just such
an easy thing to work around that it would be a petty thing to complain about.
That's the only reason I never complained about it all this time it was
annoying me. Not until I felt ready to poke around and fix it myself.

And I'm not suggesting ignoring the spec, just allowing the user to ignore it,
and not having postgres go out of its way to enforce the spec on users.

I doubt the spec says that the implementation cannot allow the syntax.

...Ok, well I wouldn't put it past the spec to do so. But it does so about
lots of things that Postgres allows. The general attitude postgres has seems
to be to extend the spec whenever it's nice for the user as long as doing so
doesn't interfere with actually supporting any spec compliant code. It's not
like postgres is a good platform for testing spec compliance of SQL code
otherwise.

It just seems excessively obnoxious to refuse queries because they don't match
a grammar precisely when the missing piece is entirely not needed by the
database. It doesn't cause any ambiguity or other problems with the SQL. It
doesn't cost a single cycle in the normal case. The code doesn't impact
anything else in the system. It's the database being intentionally nosy and
picky about something just because it can.

--
greg

pgsql-patches by date:

Previous
From: Andrew Dunstan
Date:
Subject: pg_hba.conf additional comment re local line
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_hba.conf additional comment re local line