Re: Final cleanup of SQL:1999 references

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org, Neil Conway <neilc(at)samurai(dot)com>
Subject: Re: Final cleanup of SQL:1999 references
Date: 2005-11-01 21:59:00
Message-ID: 1130882340.8300.1663.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Tue, 2005-11-01 at 14:43 -0500, Tom Lane wrote:
> Some time ago, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > Am Mittwoch, 13. Juli 2005 18:01 schrieb Simon Riggs:
> >> This doc patch replaces all inappropriate references to SQL:1999 when it
> >> is used as if it were the latest (and/or still valid) SQL standard.
> >>
> >> SQL:2003 is used in its place.

...

> > Also, phrases like "This is conforming to SQL:2003." give the wrong
> > impression that it is not conforming to SQL:1999. I think it would be less
> > confusing in these cases to simply write "This is conforming to the SQL
> > standard." and then mention in the appendix that we consider SQL:2003 to be
> > the baseline.
>
> I agree: we should just say SQL except where there is an intention to
> distinguish different versions of the spec, and in that case mention
> the earliest spec version for which the particular statement is true.
> This convention will not require any future search-and-replaces.
>
> Barring some fairly convincing objections, I am going to undo most of
> this patch later this week, and instead do it as Peter suggests.

Agreed. No need for future changes is a convincing argument.

Should we make the phrase "SQL Standard" an xref to the appropriate
section in the docs? That would help with any further confusion on this.

Best Regards, Simon Riggs

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Martijn van Oosterhout 2005-11-01 22:16:58 Re: Reducing the overhead of NUMERIC data
Previous Message Tom Lane 2005-11-01 21:54:11 Re: Reducing the overhead of NUMERIC data