Re: float and float(p) missing from table 8.1

[Bruce Momjian]

On Sun, Mar 18, 2018 at 05:11:40PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/10/static/datatype.html
> Description:
> 
> Maybe it is intentional, but the float and float(p) data types are missing
> from table 8.1
> (https://www.postgresql.org/docs/10/static/datatype.html#DATATYPE-TABLE).
> float4 and float8 are listed.

Yes, I think it is intentional and is caused by the multiple aliases we
have for numeric values.  As you probably noted from the chart, the
primary type name is 'real', which is ANSI specified, with an alias
listed as float4.  There is also double precision, with an alias of
float8.

float() is more complicated since it can be either real/float4 or double
precision/float8 depending on the length, e.g.:

CREATE TABLE test(x FLOAT(1), x2 FLOAT(25));

\d test
Table "public.test"
 Column |   Type   | Collation | Nullable | Default
+--+---+--+-
 x  | real |   |  |
 x2 | double precision |   |  |

The switch from float4/float8 happens at binary digit length 25, and
this is documented:


https://www.postgresql.org/docs/10/static/datatype-numeric.html#DATATYPE-FLOAT

PostgreSQL also supports the SQL-standard notations float and float(p)
for specifying inexact numeric types. Here, p specifies the minimum
acceptable precision in binary digits. PostgreSQL accepts float(1) to
float(24) as selecting the real type, while float(25) to float(53)
select double precision. Values of p outside the allowed range draw an
error. float with no precision specified is taken to mean double
precision.


Adding float() to that chart seems like it would add too much complexity.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +

Re: Synopsis of SELECT statement: UNION, INTERSECTION, EXCEPT

[Bruce Momjian]

On Mon, Apr  2, 2018 at 08:21:45PM -0400, Tom Lane wrote:
> Bruce Momjian  writes:
> > Based on this discussion, I have developed the attached patch which
> > tries to clarify the behavior without adding complexity.
> 
> I don't think this is an improvement, really ... in particular, it
> makes the  not self-contained, which is pretty horrible
> for psql's help.

Well, we know we are limited in how much precision we can add without
losing clarity.  I don't have any new ideas so we will just have to keep
what we have, though I do think mine was an improvement in enough areas
to warrant it.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +

Re: Blanks in the first line before the first word in the code boxes

[Magnus Hagander]

On Mon, Apr 2, 2018 at 5:59 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:

> On 4/1/18 11:55, Magnus Hagander wrote:
> > However, why does devel work fine when the others are broken. It's the
> > exact same code that's run to load the docs. The *input* to the loader
> > must also be different at some point.
>
> In devel, the raw HTML output looks like
>
> ... 
> ALTER FOREIGN TABLE [ IF EXISTS ] [ ONLY ] ...
>
> (with a line break)
>
> but before it looks like
>
> ... ALTER FOREIGN TABLE [ IF EXISTS ] [ ONLY ] ...
>
> (without a line break).
>
> So maybe some part of the processing code thinks it should do some kind
> of "indentation" here.
>
>
I think I found the problem, and pushed a fix for it. Basically it turns
off indentation completely on pre-11 versions., I elected to keep indention
on dev because it works there, and it makes debugging any of the formatting
a lot easier.

I've pushed the fix and reloaded the 10 docs. I have not reloaded earlier
branches yet, but I'd be interested in some people reviewing a bunch of
pages in the 10 docs mainly to see if (1) it fixes all the cases, and (2)
it actually breaks some *other* cases.


-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: Extra comma in documentation of array_fill

[Bruce Momjian]

On Sun, Mar 25, 2018 at 03:57:47PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/10/static/functions-array.html
> Description:
> 
> In table 9.49
> (https://www.postgresql.org/docs/10/static/functions-array.html#ARRAY-FUNCTIONS-TABLE)
> there is an extra comma in the syntax for array_fill.
> "array_fill(anyelement, int[], [, int[]])" should be "array_fill(anyelement,
> int[] [, int[]])"

This has been fixed:

commit ee4a2c4a0345f2589ce32b64493b1b14e87f0465
Author: Tom Lane 
Date:   Sun Mar 25 12:38:21 2018 -0400

Doc: remove extra comma in syntax summary for array_fill().

Noted by Scott Ure.  Back-patch to all supported branches.

Discussion: 
https://postgr.es/m/152199346794.4544.1888397173908716...@wrigleys.postgresql.org

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +