pgsql: SQL 200N -> SQL:2003
Log Message:
-----------
SQL 200N -> SQL:2003
Modified Files:
--------------
pgsql/src/backend/parser:
gram.y (r2.625 -> r2.626)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/gram.y?r1=2.625&r2=2.626)
On Mon, 2008-10-20 at 14:26 +0000, Peter Eisentraut wrote:
Log Message:
-----------
SQL 200N -> SQL:2003
Why not SQL:2008?
If it's not in latest version, it has been superceded and we should
consider removing it.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
On Mon, 2008-10-20 at 16:18 +0100, Simon Riggs wrote:
On Mon, 2008-10-20 at 14:26 +0000, Peter Eisentraut wrote:
Log Message:
-----------
SQL 200N -> SQL:2003Why not SQL:2008?
Peter?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Simon Riggs <simon@2ndQuadrant.com> writes:
On Mon, 2008-10-20 at 16:18 +0100, Simon Riggs wrote:
On Mon, 2008-10-20 at 14:26 +0000, Peter Eisentraut wrote:
SQL 200N -> SQL:2003
Why not SQL:2008?
Peter?
If the comment was meant to refer to SQL:2003 originally, it should
probably be left that way. I don't want to get into the game of doing a
global search-and-replace every time a new spec comes out. If anything,
comments referring to particular spec versions should probably make a
habit of referring to the *oldest* version in which a given feature
exists, not the newest.
regards, tom lane
On Tuesday 21 October 2008 19:59:02 Tom Lane wrote:
Simon Riggs <simon@2ndQuadrant.com> writes:
On Mon, 2008-10-20 at 16:18 +0100, Simon Riggs wrote:
On Mon, 2008-10-20 at 14:26 +0000, Peter Eisentraut wrote:
SQL 200N -> SQL:2003
Why not SQL:2008?
Peter?
If the comment was meant to refer to SQL:2003 originally, it should
probably be left that way. I don't want to get into the game of doing a
global search-and-replace every time a new spec comes out. If anything,
comments referring to particular spec versions should probably make a
habit of referring to the *oldest* version in which a given feature
exists, not the newest.
That was the idea. I don't care much one way or another, but SQL:200N is
obviously not very clear.