Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-patchespgsql-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

pgsql-patches by date

Next:From: Peter EisentrautDate: 2004-09-21 18:58:01
Subject: Re: pg_hba.conf additional comment re local line
Previous:From: Andrew DunstanDate: 2004-09-21 16:54:55
Subject: pg_hba.conf additional comment re local line

pgsql-sql by date

Next:From: Josh BerkusDate: 2004-09-21 17:53:27
Subject: Re: raise is not working
Previous:From: CHRIS HOOVERDate: 2004-09-21 16:44:00
Subject: raise is not working

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group