Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA56940 for ; Wed, 16 Feb 2000 00:14:03 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id AAA01307; Wed, 16 Feb 2000 00:12:46 -0500 (EST) To: Byron Nikolaidis cc: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] Functions vs. Columns????? In-reply-to: <38AA04D4.4FDA646C@home.com> References: <38AA04D4.4FDA646C@home.com> Comments: In-reply-to Byron Nikolaidis message dated "Tue, 15 Feb 2000 21:00:52 -0500" Date: Wed, 16 Feb 2000 00:12:45 -0500 Message-ID: <1304.950677965@sss.pgh.pa.us> From: Tom Lane Byron Nikolaidis writes: > Works Doesn't Work > ------ ------------ > select now(); select now; > select current_date; select current_date(); > It seems that there should be some consistency here in the use of > parenthesis. Consistency? Who needs consistency ;-) ? What you're seeing here is the conflict of two cultures. The SQL92 standard mandates a keyword CURRENT_DATE, with *no* parentheses, as the way to get the current date. now() comes out of the Berkeley Postquel code, which inherits from an academic tradition that doesn't like inventing reserved words without need, and also thinks that things that look like constants ought to *be* constants. The way to resolve that tension, in academese, is to invent parameterless functions. But the folks who wrote the SQL92 spec seem to have been raised on COBOL, which never met a reserved word it didn't like. Anyway, Postgres supports both the SQL92 notation and the notation we inherited from Postquel. I don't think that adding with-or- without-parentheses-take-your-pick-for-both syntax freedom would be a step forward... that path leads to way too many traps for the unwary programmer. regards, tom lane