On Thu, Dec 12, 2013 at 4:48 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Dec 11, 2013 at 2:29 PM, Tom Lane wrote:
>>> More generally, if we do go over in 9.4 to the position that PQhost
>>> reports the host parameter and nothing but, I'm not sure that introducing
>>> a third behavior in
Robert Haas writes:
> On Wed, Dec 11, 2013 at 2:29 PM, Tom Lane wrote:
>> More generally, if we do go over in 9.4 to the position that PQhost
>> reports the host parameter and nothing but, I'm not sure that introducing
>> a third behavior into the back branches is something that anybody will
>> t
On Wed, Dec 11, 2013 at 2:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Dec 11, 2013 at 2:10 PM, Tom Lane wrote:
>>> Robert Haas writes:
Well, returning /tmp on Windows is just stupid. I don't see why we
should feel bad about changing that. A bug is a bug.
>
>>> What I was
Robert Haas writes:
> On Wed, Dec 11, 2013 at 2:10 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Well, returning /tmp on Windows is just stupid. I don't see why we
>>> should feel bad about changing that. A bug is a bug.
>> What I was suggesting was we should take out the pgunixsocket fallba
On Wed, Dec 11, 2013 at 2:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Dec 11, 2013 at 11:24 AM, Tom Lane wrote:
>>> In general, I think the definition of these query functions ought to
>>> be "what was the value of this parameter when the connection was made".
>>> As such, I'm not ev
Robert Haas writes:
> On Wed, Dec 11, 2013 at 11:24 AM, Tom Lane wrote:
>> In general, I think the definition of these query functions ought to
>> be "what was the value of this parameter when the connection was made".
>> As such, I'm not even sure that the pgunixsocket behavior that's in
>> PQho
On Wed, Dec 11, 2013 at 11:24 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Dec 11, 2013 at 9:35 AM, Andres Freund
>> wrote:
>>> One use case is accessing a particular host when using DNS round robin
>>> to standbys in combination with SSL.
>
>> Ah, interesting point. And it's not incon
Robert Haas writes:
> On Wed, Dec 11, 2013 at 9:35 AM, Andres Freund wrote:
>> One use case is accessing a particular host when using DNS round robin
>> to standbys in combination with SSL.
> Ah, interesting point. And it's not inconceivable that some
> application out there could be using PQho
On Wed, Dec 11, 2013 at 9:35 AM, Andres Freund wrote:
> On 2013-12-11 08:56:43 -0500, Robert Haas wrote:
>> > $ psql -d "hostaddr=127.0.0.1"
>> > =# \conninfo
>> > You are connected to database "postgres" as user "postgres" via socket
>> > in "/tmp" at port "5432".
>>
>> Yeah, that's true. But th
On 2013-12-11 08:56:43 -0500, Robert Haas wrote:
> > $ psql -d "hostaddr=127.0.0.1"
> > =# \conninfo
> > You are connected to database "postgres" as user "postgres" via socket
> > in "/tmp" at port "5432".
>
> Yeah, that's true. But the whole point of having both host and
> hostaddr seems to be t
On Wed, Dec 11, 2013 at 8:45 AM, Fujii Masao wrote:
> On Wed, Dec 11, 2013 at 10:26 PM, Robert Haas wrote:
>> On Tue, Dec 10, 2013 at 11:40 PM, Fujii Masao wrote:
>>> While I was investigaing PQhost() for that approach, I found several
>>> problems of PQhost().
>>>
>>> (1) PQhost() can return Un
On Wed, Dec 11, 2013 at 10:26 PM, Robert Haas wrote:
> On Tue, Dec 10, 2013 at 11:40 PM, Fujii Masao wrote:
>> While I was investigaing PQhost() for that approach, I found several
>> problems of PQhost().
>>
>> (1) PQhost() can return Unix-domain socket directory path even in the
>> platform that
On Tue, Dec 10, 2013 at 11:40 PM, Fujii Masao wrote:
> While I was investigaing PQhost() for that approach, I found several
> problems of PQhost().
>
> (1) PQhost() can return Unix-domain socket directory path even in the
> platform that
> doesn't support Unix-domain socket.
>
> (2) In the pla
On Thu, Nov 21, 2013 at 9:58 PM, Fujii Masao wrote:
> On Thu, Nov 21, 2013 at 6:41 AM, Robert Haas wrote:
>> On Wed, Nov 20, 2013 at 4:55 AM, Fujii Masao wrote:
Not that I can see, but it's not very future-proof. If libpq changes
its idea of what will provoke database-name expansion,
On Thu, Nov 21, 2013 at 6:41 AM, Robert Haas wrote:
> On Wed, Nov 20, 2013 at 4:55 AM, Fujii Masao wrote:
>>> Not that I can see, but it's not very future-proof. If libpq changes
>>> its idea of what will provoke database-name expansion, this will again
>>> be broken.
>>
>> Yeah, I agree that we
On Wed, Nov 20, 2013 at 4:55 AM, Fujii Masao wrote:
>> Not that I can see, but it's not very future-proof. If libpq changes
>> its idea of what will provoke database-name expansion, this will again
>> be broken.
>
> Yeah, I agree that we should make the logic of pg_isready more future-proof
> in
On 11/20/2013 01:55 AM, Fujii Masao wrote:
> Yeah, I agree that we should make the logic of pg_isready more future-proof
> in 9.4dev. One idea is to expose internal_ping() as a libpq function. Then,
> instead of just calling PQpingParams(), we can do PQconnectStartParams(),
> libpq-function-version
On Wed, Nov 20, 2013 at 3:12 AM, Robert Haas wrote:
> On Tue, Nov 19, 2013 at 1:10 PM, Fujii Masao wrote:
>> On Tue, Nov 19, 2013 at 11:51 PM, Robert Haas wrote:
>>> On Fri, Nov 15, 2013 at 9:01 PM, Fabrízio de Royes Mello
>>> wrote:
On Wed, Nov 13, 2013 at 9:37 PM, Josh Berkus wrote:
>>>
On Tue, Nov 19, 2013 at 1:22 PM, Josh Berkus wrote:
> On 11/19/2013 10:12 AM, Robert Haas wrote:
>> On Tue, Nov 19, 2013 at 1:10 PM, Fujii Masao wrote:
>>> On Tue, Nov 19, 2013 at 11:51 PM, Robert Haas wrote:
On Fri, Nov 15, 2013 at 9:01 PM, Fabrízio de Royes Mello
http://www.postgresq
On 11/19/2013 10:12 AM, Robert Haas wrote:
> On Tue, Nov 19, 2013 at 1:10 PM, Fujii Masao wrote:
>> On Tue, Nov 19, 2013 at 11:51 PM, Robert Haas wrote:
>>> On Fri, Nov 15, 2013 at 9:01 PM, Fabrízio de Royes Mello
>>> http://www.postgresql.org/docs/9.3/static/app-pg-isready.html
>>
>> Attached is
On Tue, Nov 19, 2013 at 1:10 PM, Fujii Masao wrote:
> On Tue, Nov 19, 2013 at 11:51 PM, Robert Haas wrote:
>> On Fri, Nov 15, 2013 at 9:01 PM, Fabrízio de Royes Mello
>> wrote:
>>> On Wed, Nov 13, 2013 at 9:37 PM, Josh Berkus wrote:
handyrep@john:~/handyrep$ pg_isready --version
pg_is
On Tue, Nov 19, 2013 at 11:51 PM, Robert Haas wrote:
> On Fri, Nov 15, 2013 at 9:01 PM, Fabrízio de Royes Mello
> wrote:
>> On Wed, Nov 13, 2013 at 9:37 PM, Josh Berkus wrote:
>>> handyrep@john:~/handyrep$ pg_isready --version
>>> pg_isready (PostgreSQL) 9.3.1
>>>
>>> handyrep@john:~/handyrep$ p
On Fri, Nov 15, 2013 at 9:01 PM, Fabrízio de Royes Mello
wrote:
> On Wed, Nov 13, 2013 at 9:37 PM, Josh Berkus wrote:
>> handyrep@john:~/handyrep$ pg_isready --version
>> pg_isready (PostgreSQL) 9.3.1
>>
>> handyrep@john:~/handyrep$ pg_isready -h john -p 5432 -U postgres -d
>> postgres -q
>> pg_i
On Wed, Nov 13, 2013 at 9:37 PM, Josh Berkus wrote:
>
> handyrep@john:~/handyrep$ pg_isready --version
> pg_isready (PostgreSQL) 9.3.1
>
> handyrep@john:~/handyrep$ pg_isready -h john -p 5432 -U postgres -d
> postgres -q
> pg_isready: missing "=" after "postgres" in connection info string
>
> han
24 matches
Mail list logo
