Re: 127.0.0.1 or localhost

[Tom Lane]

PG Doc comments form  writes:
> It's not actually a problem, it's a question. pgpass in my case, has two
> lines, one with 127.0.0.1 and another with localhost
> what would be the difference from one to another. ??

AFAIR, the field is matched to how you wrote the hostname in the
connection parameters.

Also, it looks like there's a special case to consider 'localhost'
as matching a Unix-socket connection, if the socket is in the
installation's default socket directory.

regards, tom lane

127.0.0.1 or localhost

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/9.5/libpq-pgpass.html
Description:

Hi All, 

It's not actually a problem, it's a question. pgpass in my case, has two
lines, one with 127.0.0.1 and another with localhost

what would be the difference from one to another. ??

Re: Missing file is mentioned on page https://www.postgresql.org/docs/13/libpq-exec.html

[Tom Lane]

Euler Taveira  writes:
> On Tue, 27 Oct 2020 at 13:54, Bruce Momjian  wrote:
>> Uh, in my source tree that is a symlink to
>> src/backend/catalog/pg_type_d.h, but that file is generated by
>> src/backend/catalog/genbki.pl.  Does that help you?

> Shouldn't we replace "are defined in the file" with "are defined in the
> generated file"? That's the only place that mentions *_d.h files. Perhaps
> adding a link to BKI [1] should avoid further questions.

It'd probably confuse users more, actually.  This chapter is aimed at
users of Postgres, not developers.

>From a user's viewpoint, catalog/pg_type_d.h should look pretty much
like any other installed header.  We want to point them at that, not at
pg_type.h, because the latter is painful to include in application code
that doesn't want to buy into the Postgres programming environment
altogether.

Thinking about it from the perspective of someone dealing with an
installation tree not a source tree, maybe the reference should
be to "server/catalog/pg_type_d.h".  That might help disabuse
anyone who's expecting to find it at that path in the git tree.

regards, tom lane

Re: Missing file is mentioned on page https://www.postgresql.org/docs/13/libpq-exec.html

[Euler Taveira]

On Tue, 27 Oct 2020 at 13:54, Bruce Momjian  wrote:

> On Tue, Oct 27, 2020 at 10:48:00AM +, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/13/libpq-exec.html
> > Description:
> >
> > On page https://www.postgresql.org/docs/13/libpq-exec.html, non-existing
> > file is mentioned: src/include/catalog/pg_type_d.h. We fail to find it in
> > this catalog:
> >
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=tree;f=src/include/catalog;hb=HEAD
> .
>
> Uh, in my source tree that is a symlink to
> src/backend/catalog/pg_type_d.h, but that file is generated by
> src/backend/catalog/genbki.pl.  Does that help you?
>
>
Shouldn't we replace "are defined in the file" with "are defined in the
generated file"? That's the only place that mentions *_d.h files. Perhaps
adding a link to BKI [1] should avoid further questions.

[1] https://www.postgresql.org/docs/13/bki.html


-- 
Euler Taveira http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: physical should be logical

[Euler Taveira]

On Tue, 27 Oct 2020 at 12:42, PG Doc comments form 
wrote:

>
> On this page,
> https://www.postgresql.org/docs/12/logical-replication-publication.html
>
> The first line states: A publication can be defined on any physical
> replication master.
> I have the impression that this should be "logical", not "physical".
>
> Although the statement contains terminology that confuses who is reading,
it is
correct. "physical replication master" means a read-write server. Maybe we
should change this sentence to: "A publication can be defined on any primary
server.". Hence, it avoids the term "physical" that should confuse readers.


-- 
Euler Taveira http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: COPY statement: no list of the allowed values for "format_name"

[Bryn Llewellyn]

PG Doc comments form wrote:

Look at the account of the COPY statement, here:

https://www.postgresql.org/docs/11/sql-copy.html 


and see this:
«
[ [ WITH ] ( option [, ...] ) ]
»

It goes on to say this:

«
where option can be one of:

   FORMAT format_name
»

But there's no list of the allowed values for "format_name". The same holds for 
other options like, for example, "encoding_name”.

David G. Johnston  wrote:

Keep reading…

"""
FORMAT
Selects the data format to be read or written: text, csv (Comma Separated 
Values), or binary. The default is text.
"""

I suppose including the syntax term "format_type" might help, but the all-caps 
FORMAT is definitive.


Thanks for the quick reply, David. I do think that it’s reasonable to expect to 
search in the page rather than to have to read every word from top to bottom in 
the class of use cases that my example indicates. FORMAT is the syntax keyword; 
and format_name denotes the value. I think that this present sentence:

«
Selects the data format to be read or written: text, csv (Comma Separated 
Values), or binary. The default is text.
»

would be improved if it were spelled more explicitly:

«
Selects the data format to be read or written. The allowed values for 
format_name are text, csv (Comma Separated Values), or binary. The default is 
text.
»

Please consider making this change (and the convention that it implies for 
comparable cases).