BUG #14135: SQL command "analyse" is undocumented

On Thursday, May 12, 2016, <ville@torhonen.fi> wrote:

The following bug has been logged on the website:

Bug reference: 14135
Logged by: Ville Törhönen
Email address: ville@torhonen.fi <javascript:;>
PostgreSQL version: 9.5.2
Operating system: CentOS 6.5
Description:

Hello,

On PostgreSQL 9.5.2 SQL commands "analyze" and "analyse" run exactly the
same thing. However, the "analyse" command is completely undocumented.

postgres=# \h analyze
Command: ANALYZE
Description: collect statistics about a database
Syntax:
ANALYZE [ VERBOSE ] [ table_name [ ( column_name [, ...] ) ] ]

postgres=# \h analyse
No help available for "analyse".
Try \h with no arguments to see available help.

Tab completion does not acknowledge "analyse" command. Product
documentation
[1] states that the command "analyse" is reserved, but "Appendix C: SQL Key
Words" is the only page in the whole documentation that mentions the word
"analyse".

Tested with the following PostgreSQL RPM packages from PostgreSQL yum
repository (yum.postgresql.org):

postgresql95-libs-9.5.2-1PGDG.rhel6.x86_64
postgresql95-server-9.5.2-1PGDG.rhel6.x86_64
postgresql95-9.5.2-1PGDG.rhel6.x86_64
postgresql95-contrib-9.5.2-1PGDG.rhel6.x86_64
postgresql95-devel-9.5.2-1PGDG.rhel6.x86_64

The alias should be documented but I would not think it should be part of
tab completion.

I'd probably add a note to the analyze areas and, for \h analyse, redirect
to analyze.

I think altering the syntax would just be noise for little gain. My goal
is if someone sees or types analyse they at least know it's intended
behavior and indeed an alias.

Not at a terminal now but hopefully the analyze option to vacuum and
explain behave similarly...

David J.

On Thu, May 12, 2016 at 11:05 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:

The alias should be documented but I would not think it should be part of
tab completion.

I'd probably add a note to the analyze areas and, for \h analyse, redirect
to analyze.

I think altering the syntax would just be noise for little gain. My goal is
if someone sees or types analyse they at least know it's intended behavior
and indeed an alias.

Not at a terminal now but hopefully the analyze option to vacuum and explain
behave similarly...

Some history shows up that:
commit: ebe0b236909732c75d665c73363bd4ac7a7aa138
author: Bruce Momjian <bruce@momjian.us>
date: Wed, 8 Nov 2000 21:28:06 +0000
Add ANALYSE spelling of ANALYZE for vacuum.

I am not sure that it is worth complicating the docs for the British
spelling of this word.
--
Michael

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Michael Paquier <michael.paquier@gmail.com> writes:

I am not sure that it is worth complicating the docs for the British
spelling of this word.

I agree. If someone were to hold my feet to the fire about that,
I'd vote for taking out the ANALYSE spelling rather than documenting
it. But I'd rather leave it alone, since no doubt some of the British
contingent are used to being able to spell it that way, even if the
docs don't say that they can.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On 05/12/2016 05:15 PM, Tom Lane wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

I am not sure that it is worth complicating the docs for the British
spelling of this word.

I agree. If someone were to hold my feet to the fire about that,
I'd vote for taking out the ANALYSE spelling rather than documenting
it. But I'd rather leave it alone, since no doubt some of the British
contingent are used to being able to spell it that way, even if the
docs don't say that they can.

I was involved in a project whereby the client had written an app to
filter/control what could be executed by their developers (via a web
interface), and since ANALYSE was undocumented they missed it. I was
aware of it and pointed it out during an audit of their app.

Personally I would vote to either document it or rip it out, but I don't
think the status quo is good.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

On Fri, May 13, 2016 at 9:23 AM, Joe Conway <mail@joeconway.com> wrote:

On 05/12/2016 05:15 PM, Tom Lane wrote:

I agree. If someone were to hold my feet to the fire about that,
I'd vote for taking out the ANALYSE spelling rather than documenting
it. But I'd rather leave it alone, since no doubt some of the British
contingent are used to being able to spell it that way, even if the
docs don't say that they can.

I was involved in a project whereby the client had written an app to
filter/control what could be executed by their developers (via a web
interface), and since ANALYSE was undocumented they missed it. I was
aware of it and pointed it out during an audit of their app.

Personally I would vote to either document it or rip it out, but I don't
think the status quo is good.

If the choice is only between those two, I'd vote for nuking it and
simplify the code, but honestly the current statu-quo has been running
for 16 years and there are not many complains about it, so as a third
choice the current situation is fine IMO. And it does not represent an
extra maintenance load.
--
Michael

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Fri, May 13, 2016 at 1:49 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:

On Fri, May 13, 2016 at 9:23 AM, Joe Conway <mail@joeconway.com> wrote:

On 05/12/2016 05:15 PM, Tom Lane wrote:

I agree. If someone were to hold my feet to the fire about that,
I'd vote for taking out the ANALYSE spelling rather than documenting
it. But I'd rather leave it alone, since no doubt some of the British
contingent are used to being able to spell it that way, even if the
docs don't say that they can.

I was involved in a project whereby the client had written an app to
filter/control what could be executed by their developers (via a web
interface), and since ANALYSE was undocumented they missed it. I was
aware of it and pointed it out during an audit of their app.

Personally I would vote to either document it or rip it out, but I don't
think the status quo is good.

If the choice is only between those two, I'd vote for nuking it and
simplify the code, but honestly the current statu-quo has been running
for 16 years and there are not many complains about it, so as a third
choice the current situation is fine IMO. And it does not represent an
extra maintenance load.

It's strange that this one keyword has been singled out for
transatlantic treatment, and it's good news that it's not documented.
We don't accept CATALOGUE, SERIALISABLE, MATERIALISED, AUTHORISATION
etc, and those like me who usually use those spellings in prose are
doing just fine with this exotic Californian software. +1 for nuking
it.

--
Thomas Munro
http://www.enterprisedb.com

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs