On 02/04/2010 09:37 AM, Joe Conway wrote:
> On 02/04/2010 08:31 AM, Joe Conway wrote:
>> On 02/04/2010 01:23 AM, Fujii Masao wrote:
>>> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
OK, this one includes pg_dump(all)/pg_restore and common.c from
bin/scripts (createdb, vacuumdb, etc).
On 02/04/2010 08:31 AM, Joe Conway wrote:
> On 02/04/2010 01:23 AM, Fujii Masao wrote:
>> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
>>> OK, this one includes pg_dump(all)/pg_restore and common.c from
>>> bin/scripts (createdb, vacuumdb, etc). I still need to adjust the docs,
>>> but other
On 02/04/2010 01:23 AM, Fujii Masao wrote:
> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
>> OK, this one includes pg_dump(all)/pg_restore and common.c from
>> bin/scripts (createdb, vacuumdb, etc). I still need to adjust the docs,
>> but other than that any remaining complaints?
> * expand_
On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
> On 02/02/2010 10:23 PM, Tom Lane wrote:
>> Joe Conway writes:
>>> Should I also be looking to replace all (or most) other instances of
>>> PQsetdbLogin()?
>>
>> I think we at least wanted to fix pg_dump(all)/pg_restore. Not sure if
>> the other
On 02/02/2010 10:23 PM, Tom Lane wrote:
> Joe Conway writes:
>> Should I also be looking to replace all (or most) other instances of
>> PQsetdbLogin()?
>
> I think we at least wanted to fix pg_dump(all)/pg_restore. Not sure if
> the others are worth troubling over.
OK, this one includes pg_dump
Joe Conway writes:
> Should I also be looking to replace all (or most) other instances of
> PQsetdbLogin()?
I think we at least wanted to fix pg_dump(all)/pg_restore. Not sure if
the others are worth troubling over.
regards, tom lane
--
Sent via pgsql-bugs mailing list
On 02/02/2010 10:08 PM, Tom Lane wrote:
> Joe Conway writes:
>> Are there any of the psql parameters that we do not want to allow to be
>> overridden by the conninfo string?
>
> Actually, now that I think about it, psql shouldn't be setting
> application_name at all. It should be setting
> fallb
Joe Conway writes:
> Are there any of the psql parameters that we do not want to allow to be
> overridden by the conninfo string?
Actually, now that I think about it, psql shouldn't be setting
application_name at all. It should be setting
fallback_application_name, and I think that should be aft
On 02/02/2010 06:40 PM, Tom Lane wrote:
> The difference with PQconnectdbParams is that the dbname might not be
> the first thing in the parameter array. I think that a straightforward
> implementation would have the effect of the expanded dbname overriding
> parameters given before it, but not th
Joe Conway writes:
> On 02/02/2010 06:10 PM, Tom Lane wrote:
>> We should also give more than zero thought to how values coming from the
>> expanded dbname should interact with values from other arguments to
>> PQconnectdbParams --- which should override which? And should there be
>> an order dep
On 02/02/2010 06:10 PM, Tom Lane wrote:
> Since we haven't yet released PQconnectdbParams, it's not too late
> to twiddle its API. What I'm thinking about is an additional
> boolean parameter "expand_dbname", which only if true would enable
> treating an equal-sign-containing dbname like a conninf
Fujii Masao writes:
> On Wed, Feb 3, 2010 at 10:05 AM, Joe Conway wrote:
>> Objections?
> I think that PQconnectdbParams() rather than psql should handle the
> dbname containing "=". Otherwise whenever we use PQconnectdbParams(),
> we would have to check for the content of the dbname before call
On 02/02/2010 05:59 PM, Tom Lane wrote:
> This seems bogus on a couple of levels. First off, I thought the idea
> was to get away from using PQsetdbLogin at all. If we go down this path
> we'll never be rid of it. Second, to preserve backwards compatibility
> we will have to duplicate this same
Joe Conway writes:
> If "=" is found in the dbname psql argument, the argument is assumed to
> be a conninfo string. In that case, append application_name to the
> conninfo and use PQsetdbLogin() as before. Otherwise use the new
> PQconnectdbParams().
This seems bogus on a couple of levels. Firs
On 02/02/2010 05:46 PM, Fujii Masao wrote:
> On Wed, Feb 3, 2010 at 10:05 AM, Joe Conway wrote:
>> Objections?
>
> I think that PQconnectdbParams() rather than psql should handle the
> dbname containing "=". Otherwise whenever we use PQconnectdbParams(),
> we would have to check for the content o
On Wed, Feb 3, 2010 at 10:05 AM, Joe Conway wrote:
> Here's a patch.
Thanks!
> If "=" is found in the dbname psql argument, the argument is assumed to
> be a conninfo string. In that case, append application_name to the
> conninfo and use PQsetdbLogin() as before. Otherwise use the new
> PQconne
On 02/01/2010 08:06 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Fujii Masao wrote:
>>> In HEAD, psql using conninfo fails in connecting to the server as follows.
>>>
>>> $ bin/psql "host=localhost"
>>> psql: FATAL: database "host=localhost" does not exist
>>>
>>> This is because the recen
On 02/01/2010 08:06 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Fujii Masao wrote:
>>> In HEAD, psql using conninfo fails in connecting to the server as follows.
>>>
>>> $ bin/psql "host=localhost"
>>> psql: FATAL: database "host=localhost" does not exist
>>>
>>> This is because the recen
Heikki Linnakangas writes:
> Fujii Masao wrote:
>> In HEAD, psql using conninfo fails in connecting to the server as follows.
>>
>> $ bin/psql "host=localhost"
>> psql: FATAL: database "host=localhost" does not exist
>>
>> This is because the recently-introduced PQconnectStartParams()
>> doesn'
2010/2/1 Fujii Masao :
> On Mon, Feb 1, 2010 at 5:31 PM, Heikki Linnakangas
> wrote:
>> Fujii Masao wrote:
>>> In HEAD, psql using conninfo fails in connecting to the server as follows.
>>>
>>> $ bin/psql "host=localhost"
>>> psql: FATAL: database "host=localhost" does not exist
>>>
>>> This
On Mon, Feb 1, 2010 at 5:31 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> In HEAD, psql using conninfo fails in connecting to the server as follows.
>>
>> $ bin/psql "host=localhost"
>> psql: FATAL: database "host=localhost" does not exist
>>
>> This is because the recently-introduced
Fujii Masao wrote:
> In HEAD, psql using conninfo fails in connecting to the server as follows.
>
> $ bin/psql "host=localhost"
> psql: FATAL: database "host=localhost" does not exist
>
> This is because the recently-introduced PQconnectStartParams()
> doesn't handle correctly the dbname par
The following bug has been logged online:
Bug reference: 5304
Logged by: Fujii Masao
Email address: masao.fu...@gmail.com
PostgreSQL version: HEAD
Operating system: RHEL5.1
Description:psql using conninfo fails in connecting to the server
Details:
In HEAD, psql usin
23 matches
Mail list logo
