Re: Section 4.1.2.7 contains false information

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "Jind?ich Vavru?ka" <jindrich(at)vavruska(dot)cz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-docs(at)lists(dot)postgresql(dot)org" <pgsql-docs(at)lists(dot)postgresql(dot)org>
Subject: Re: Section 4.1.2.7 contains false information
Date: 2019-04-09 22:59:22
Message-ID: CAKFQuwYXhvhr8hWd1ZjWedediHiC2pY4SrvOwSNDVu8sguBhdQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On Tue, Apr 9, 2019 at 3:03 PM Jind?ich Vavru?ka <jindrich(at)vavruska(dot)cz>
wrote:

> Dear Tom, it works only in psql, it does not work when you talk to the
> server using postgresql protocol. That is my point.
>
> e.g. in the following code the query causes Syntax error (see the text in
> red). That means it does not work. Interestingly, when I use $4::timestamp or
> CAST ( $4 as TIMESTAMP ) the syntax error does not occur.
>
>
>
> "INSERT INTO public.contest (contest_id, period_id, contest_name,
> start_ts, end_ts, default_format, status ) "
>
> + "VALUES ($1, $2, $3, *TIMESTAMP $4*, *TIMESTAMP $5*, $6, 'NEW'
> ) RETURNING contest_key",
>
>
> And further on in that section its plainly states:

"To avoid syntactic ambiguity, the type 'string' syntax can only be used to
specify the type of a simple literal constant."

Since what you've provided is not a simple literal constant it is expected
to not work - and that either :: or cast() needs to be used instead.

If you'd like to make a concrete documentation suggestion please do so.
Given the scarcity of complaints seen here, and the fact that not
everything can and should be documented everywhere, I'm not presently
seeing an issue large enough to change the status quo. Especially since
its sounds more like you didn't read the section the explicitly covers the
limitations of typename 'literal' and the universality of actual casting
syntax (either SQL standard CAST or PostgreSQL double-colon).

There is indeed a lot of material here and sometime a quick question on the
email lists is more efficient a learning mechanism than trying to get the
documentation perfect. This seems like one of those times.

David J.

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message PG Doc comments form 2019-04-10 08:58:10 JOINS example
Previous Message Bruce Momjian 2019-04-09 21:44:12 Re: asynchronous commit risk window is overly optimistic