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

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

In response to

Browse pgsql-patches by date

  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

Browse pgsql-sql by date

  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