On 07/10/2017 01:47 PM, Arthur Zakirov wrote:
Hello,
2017-07-10 12:30 GMT+03:00 Heikki Linnakangas :
I just remembered that this was still pending. I made the documentation
changes, and committed this patch now.
We're uncomfortably close to wrapping the next beta, later today, but I
think it
Hello,
2017-07-10 12:30 GMT+03:00 Heikki Linnakangas :
>
>
> I just remembered that this was still pending. I made the documentation
> changes, and committed this patch now.
>
> We're uncomfortably close to wrapping the next beta, later today, but I
> think it's better to get this into the hands o
On 06/09/2017 04:26 PM, Robert Haas wrote:
On Fri, Jun 9, 2017 at 6:36 AM, Heikki Linnakangas wrote:
Right. I think it's a usability fail as it is; it certainly fooled me. We
could make the error messages and documentation more clear. But even better
to allow multiple host addresses, so that it
On Fri, Jun 9, 2017 at 11:52 AM, Heikki Linnakangas wrote:
> On 06/09/2017 05:47 PM, Jeff Janes wrote:
>
>> Your commit to fix this part, 76b11e8a43eca4612d, is giving me compiler
>> warnings:
>>
>> fe-connect.c: In function 'connectDBStart':
>> fe-connect.c:1625: warning: 'ret' may be used unini
On 06/09/2017 05:47 PM, Jeff Janes wrote:
Your commit to fix this part, 76b11e8a43eca4612d, is giving me compiler
warnings:
fe-connect.c: In function 'connectDBStart':
fe-connect.c:1625: warning: 'ret' may be used uninitialized in this function
gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC
Jeff Janes writes:
> Your commit to fix this part, 76b11e8a43eca4612d, is giving me compiler
> warnings:
> fe-connect.c: In function 'connectDBStart':
> fe-connect.c:1625: warning: 'ret' may be used uninitialized in this function
Me too ...
> gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC)
On Thu, Jun 8, 2017 at 1:36 AM, Heikki Linnakangas wrote:
> While testing libpq and GSS the other day, I was surprised by the behavior
> of the host and hostaddr libpq options, if you specify a list of hostnames.
>
> I did this this, and it took me quite a while to figure out what was going
> on:
On Fri, Jun 9, 2017 at 6:36 AM, Heikki Linnakangas wrote:
> Right. I think it's a usability fail as it is; it certainly fooled me. We
> could make the error messages and documentation more clear. But even better
> to allow multiple host addresses, so that it works as you'd expect.
Sure, I don't h
On 06/08/2017 06:18 PM, Robert Haas wrote:
On Thu, Jun 8, 2017 at 10:50 AM, Tom Lane wrote:
Robert Haas writes:
It doesn't seem like a problem to me if somebody else wants to extend
it to hostaddr, though. Whether that change belongs in v10 or v11 is
debatable. I would object to adding this
On Fri, Jun 9, 2017 at 3:22 PM, Heikki Linnakangas wrote:
> Hmm, there is one problem with our current use of comma as a separator:
you
> cannot use a Unix-domain socket directory that has a comma in the name,
> because it's interpreted as multiple hostnames. E.g. this doesn't work:
>
> psql "host
On 06/08/2017 06:39 PM, David G. Johnston wrote:
These are already failing so I'd agree that explicit rejection isn't
necessary - the question seems restricted to usability. Though I suppose
we need to consider whether there is any problem with the current setup if
indeed our intended separator
On Thu, Jun 8, 2017 at 8:18 AM, Robert Haas wrote:
> Whatever you put in the hostaddr field - or any field other than host
> and port - is one entry. There is no notion of a list of entries in
> any other field, and no attempt to split any other field on a comma or
> any other symbol.
>
[...]
On Thu, Jun 8, 2017 at 10:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> It doesn't seem like a problem to me if somebody else wants to extend
>> it to hostaddr, though. Whether that change belongs in v10 or v11 is
>> debatable. I would object to adding this as an open item with me as
>> the o
Robert Haas writes:
> It doesn't seem like a problem to me if somebody else wants to extend
> it to hostaddr, though. Whether that change belongs in v10 or v11 is
> debatable. I would object to adding this as an open item with me as
> the owner because doesn't seem to me to be a must-fix issue,
On Thu, Jun 8, 2017 at 4:36 AM, Heikki Linnakangas wrote:
> So, this is all quite confusing. I think we should support a list of
> hostaddrs, to go with the list of hostnames. It seems like a strange
> omission. Looking at the archives, it was mentioned a few times when this
> was developed and re
Heikki Linnakangas writes:
> So, this is all quite confusing. I think we should support a list of
> hostaddrs, to go with the list of hostnames. It seems like a strange
> omission.
+1, if it's not too large a patch. It could be argued that this is
a new feature and should wait for v11, but the
While testing libpq and GSS the other day, I was surprised by the
behavior of the host and hostaddr libpq options, if you specify a list
of hostnames.
I did this this, and it took me quite a while to figure out what was
going on:
$ psql "dbname=postgres hostaddr=::1 host=localhost,localhos
17 matches
Mail list logo
