From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, mailreg(at)numerixtechnology(dot)de, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [SQL] COUNT(*) to find records which have a certain number of dependencies ? |
Date: | 2004-09-21 17:14:15 |
Message-ID: | 878yb3fst4.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches pgsql-sql |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Greg Stark <gsstark(at)mit(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2004-09-21 18:58:01 | Re: pg_hba.conf additional comment re local line |
Previous Message | Andrew Dunstan | 2004-09-21 16:54:55 | pg_hba.conf additional comment re local line |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-09-21 17:53:27 | Re: raise is not working |
Previous Message | CHRIS HOOVER | 2004-09-21 16:44:00 | raise is not working |