On 2019-Sep-10, Alvaro Herrera from 2ndQuadrant wrote:
> I propose to settle this issue by applying "Robert's changes two and
> three", which has been +1'd by two people already and I also accept
> myself as improvement. I don't think any further changes are required.
Applied, marked item
I propose to settle this issue by applying "Robert's changes two and
three", which has been +1'd by two people already and I also accept
myself as improvement. I don't think any further changes are required.
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index
On 2/22/19 9:44 PM, Fabien COELHO wrote:
Hmmm, I do not buy the typing argument: "host" is actually for
everything, including directories. I do not think that adding "hostdir"
would be desirable.
In any case, the existing doco never comes out and states either
rule set in so many words.
Hello Tom,
However, it does not discuss that an IP can (and should, IMHO) be given
through "host" if the point is to specify the target by its IP rather than
a lookup shortcut.
Ah, that's the crux of the problem.
Yep!
There are two ways that you could consider to be "best practice" for
On Thu, Feb 21, 2019 at 10:57 AM Tom Lane wrote:
> True, but isn't that because we fail to document at all that you
> can put an IP address in "host"? Which your proposed patch didn't
> change, IIRC.
Well, that's another way to tackle the problem. Personally, I see
pretty much no downside in
Robert Haas writes:
> From my point of view, the issue here is that the way the
> documentation is written right now tends to lead people to believe
> that if they have a host name, they must pass it via host, and if they
> have an IP address, they must pass it via hostaddr. Thus pgAdmin 3,
> at
Fabien COELHO writes:
> However, it does not discuss that an IP can (and should, IMHO) be given
> through "host" if the point is to specify the target by its IP rather than
> a lookup shortcut.
Ah, that's the crux of the problem. There are two ways that you could
consider to be "best
On Thu, Feb 21, 2019 at 10:33 AM Tom Lane wrote:
> Sure, you only need it if you want to bypass DNS lookup, but if you
> do that, you don't necessarily need to give "host" as well. Changing
> the documentation to imply that you do would not be an improvement.
>From my point of view, the issue
Fabien COELHO writes:
>> My only complaint about this is that it makes it sound like you *must*
>> provide "host", even when giving "hostaddr":
> That is the idea, "hostaddr" is moslty never needed.
Sure, you only need it if you want to bypass DNS lookup, but if you
do that, you don't
Hello Tom,
My only complaint about this is that it makes it sound like you *must*
provide "host", even when giving "hostaddr":
That is the idea, "hostaddr" is moslty never needed.
It is the initial misleading issue I've been complaining about: one can
specify an IP *both* in host
Hello Robert,
(2) you are not against improving the documentation, although you find it
clear enough already, but you agree that some people could get confused.
The attached patch v4 only improves the documentation so that it reflects
what the implementation really does. I think it too bad
On Wed, Feb 20, 2019 at 08:12:55PM -0500, Tom Lane wrote:
> The second para explains the cases in which you actually do need to
> provide "host", but I'm afraid that the first sentence will have
> misled people enough that they won't get the point.
>
> I don't think there's anything very wrong
Robert Haas writes:
>> Robert, any chance you could opine on the doc patch, given that's your
>> suggested direction?
> I find it to be a more change than we really need, and I'm not sure
> how much it helps to clarify the issue at hand. Here is a simpler
> change which seems like it might do
On Thu, Feb 14, 2019 at 1:10 PM Andres Freund wrote:
> > (2) you are not against improving the documentation, although you find it
> > clear enough already, but you agree that some people could get confused.
> >
> > The attached patch v4 only improves the documentation so that it reflects
> >
I am getting error while applying patch.I think the patch needs to be
redone on the latest code in master as there are some commits in master
after the patch is created
Possibly. Here is a v5 with a simplified text.
The key point is to tell that "host" expects names, ips or directories,
and
Hi,
I am getting error while applying patch.I think the patch needs to be
redone on the latest code in master as there are some commits in master
after the patch is created
On Sat, 16 Feb 2019 at 13:44, Fabien COELHO wrote:
>
> Hello Kyotaro-san,
>
> > On such standpoint, the first hunk in the
Hello Kyotaro-san,
On such standpoint, the first hunk in the patch attracted my
eyes.
host
-Name of host to connect to.host
name
-If a host name begins with a slash, it specifies Unix-domain
-communication rather than TCP/IP communication; the
Hello.
At Thu, 14 Feb 2019 22:51:40 +0100 (CET), Fabien COELHO
wrote in
>
> > On 2018-10-26 09:21:51 +0200, Fabien COELHO wrote:
> >> (1) you are somehow against changing the current implementation, eg
> >> erroring
> >> out on possibly misleading configurations, because you do not think it
>
On 2018-10-26 09:21:51 +0200, Fabien COELHO wrote:
(1) you are somehow against changing the current implementation, eg erroring
out on possibly misleading configurations, because you do not think it is
really useful to help users in those cases.
I find this formulation somewhat passive
Hi,
On 2018-10-26 09:21:51 +0200, Fabien COELHO wrote:
> (1) you are somehow against changing the current implementation, eg erroring
> out on possibly misleading configurations, because you do not think it is
> really useful to help users in those cases.
I find this formulation somewhat passive
On Fri, Nov 30, 2018 at 01:08:51PM +0100, Dmitry Dolgov wrote:
> Why then not split the original proposal into two patches, one to improve the
> documentation, and another to make it more user friendly?
Moved to next CF for now. From what I can see the latest patch
manipulates the same areas of
> On Fri, Oct 26, 2018 at 9:22 AM Fabien COELHO wrote:
>
> To sum up:
>
> (1) you are somehow against changing the current implementation, eg
> erroring out on possibly misleading configurations, because you do not
> think it is really useful to help users in those cases.
>
> (2) you are not
Hello Robert,
[...] that's a self-inflicted injury.
Sure. I'm trying to be more user friendly.
It's not that I am opposed to helping people avoid self-inflicted
injuries, but this one doesn't seem either likely or serious.
If I'm trying to improve something, I tend to be thorough about
On Thu, Oct 25, 2018 at 1:06 PM Fabien COELHO wrote:
> If you do it, even by accident, there is no way to guess what is wrong
> because the reported informations are inconsistent and does not reflect
> the actual status.
Meh. The reported information is fine. If you tell the system that
Hello Robert,
I think this patch is a solution in search of a problem.
I take note of this negative opinion.
[...] It's true that the above example is very confusing, but there's no
reason for everybody to ever do that.
If you do it, even by accident, there is no way to guess what is
On Mon, Aug 20, 2018 at 7:32 AM Fabien COELHO wrote:
>sh> psql "host=localhost,127.0.0.2,, hostaddr=127.0.0.1,,127.0.0.3,"
># attempt 1 is 127.0.0.1 identified as localhost
># attempt 2 is 127.0.0.2
># attempt 3 is 127.0.0.3 identified as the default, whatever it is
># attempt
Hello Arthur,
sh> psql "host=127.0.0.2 hostaddr=127.0.0.1"
I'm not sure that is is the issue. User defined the host name and psql
show it.
The issue is that "host" is an ip, "\conninfo" will inform wrongly that you
are connected to "127.0.0.2", but the actual connection is really to
Sorry for late answer.
On 9/30/18 10:21 AM, Fabien COELHO wrote:
sh> psql "host=127.0.0.2 hostaddr=127.0.0.1"
I'm not sure that is is the issue. User defined the host name and psql
show it.
The issue is that "host" is an ip, "\conninfo" will inform wrongly that
you are connected to
So I'm speculating that the cfbot is using a version of patch(1) that
doesn't have strip-trailing-CRs logic. Which bemuses me, because
I thought they all did.
Huh. Yeah. I have now switched it over to GNU patch. It seems to be
happier with Fabien's patches so far, but will take a few
Hello Arthur,
Thanks for the comments.
However, the actual capability is slightly different: specifying an ip
address to "host" does work, without ensuing any name or reverse name
look-ups, even if this is undocumented.
Agree it may have more details within the documentation.
sh> psql
On Sat, Aug 25, 2018 at 7:25 AM Tom Lane wrote:
> Fabien COELHO writes:
> > Attached is a rebase after 5ca00774.
>
> I notice that the cfbot thinks that *none* of your pending patches apply
> successfully. I tried this one locally and what I get is
>
> $ patch -p1 <~/libpq-host-ip-2.patch
>
Hello,
On Fri, Aug 24, 2018 at 11:22:47AM +0200, Fabien COELHO wrote:
> Attached is a rebase after 5ca00774.
I looked a little bit the patch. And I have a few notes.
> However, the actual capability is slightly different: specifying an ip
> address to "host" does work, without ensuing any name
I notice that the cfbot thinks that *none* of your pending patches apply
successfully. I tried this one locally and what I get is
Hmmm. :-(
I've reverted to sending MIME conformant "text/x-diff" CRLF attachements,
as "text/plain" did the same and you complained rightfully that
The attached patch does 1-3 (2 without renaming, though).
Attached is a rebase after 5ca00774.
--
Fabien.diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 5e7931ba90..086172d4f0 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -964,22 +964,28 @@
34 matches
Mail list logo
