Thread: .pgpass does not work for createlang

.pgpass does not work for createlang

From
"John Shin"
Date:
It seems that for v8.0.4 the createlang will not take .pgpass inputs and
always prompts for password.  Is this broken for the new version?  Well,
now I have to type in the password for my database script.

=20

-bash-3.00$ createdb test -h localhost -U postgres

CREATE DATABASE

-bash-3.00$ createlang plpgsql test -h localhost -U postgres

Password:

=20

=20

Running FC4 and PostgreSQL 8.0.4

=20

=20

John

=20

Re: .pgpass does not work for createlang

From
Michael Fuhr
Date:
On Mon, Oct 10, 2005 at 06:25:59PM -0700, John Shin wrote:
> It seems that for v8.0.4 the createlang will not take .pgpass inputs and
> always prompts for password.  Is this broken for the new version?  Well,
> now I have to type in the password for my database script.
>
> -bash-3.00$ createdb test -h localhost -U postgres
> CREATE DATABASE

Is that the exact command you ran?  As shown it should fail with a
syntax error because the options are in the wrong place:

% createdb test -h localhost -U postgres
createdb: too many command-line arguments (first is "localhost")
Try "createdb --help" for more information.

> -bash-3.00$ createlang plpgsql test -h localhost -U postgres
> Password:

Likewise:

% createlang plpgsql test -h localhost -U postgres
createlang: too many command-line arguments (first is "-h")
Try "createlang --help" for more information.

Use the --help option or consult the createlang documentation to see
the correct order of options and arguments.  It works fine here with
.pgpass if the syntax is correct; have you run "createlang --version"
to verify that you're running the 8.0.4 version?

--
Michael Fuhr

Re: .pgpass does not work for createlang

From
Michael Fuhr
Date:
[Please copy the mailing list on replies so others can participate
in and learn from the discussion.]

On Tue, Oct 11, 2005 at 11:16:40AM -0700, John Shin wrote:
> Tried many diffent ways but nothing seems to stick for createlang.
> .pgpass works for all others (createdb, dropdb, createuser, dropuser,
> etc.)

[snip]

> -bash-3.00$ createdb test -h localhost -U postgres
> CREATE DATABASE

Hmmm...this command fails with "too many command-line arguments"
on both FreeBSD and Solaris (8.0.4 built from source on both), so
I wonder if your build is using a getopt_long() that behaves
differently than what I'm using.  Might not matter, though.

> -bash-3.00$ createlang -h localhost -U postgres plpgsql test
> Password:

Have you done a process trace (strace, ktrace, truss, etc.) to see
if createlang is even looking for .pgpass?  Does it work if you
set the PGUSER environment variable instead of using the -U option?

You mentioned FC4, so maybe Tom Lane or somebody more familiar
with that platform has some ideas about what's happening.

--
Michael Fuhr

Re: .pgpass does not work for createlang

From
Tom Lane
Date:
Michael Fuhr <mike@fuhr.org> writes:
> On Tue, Oct 11, 2005 at 11:16:40AM -0700, John Shin wrote:
>> Tried many diffent ways but nothing seems to stick for createlang.
>> .pgpass works for all others (createdb, dropdb, createuser, dropuser,
>> etc.)

>> -bash-3.00$ createdb test -h localhost -U postgres
>> CREATE DATABASE

> Hmmm...this command fails with "too many command-line arguments"
> on both FreeBSD and Solaris (8.0.4 built from source on both), so
> I wonder if your build is using a getopt_long() that behaves
> differently than what I'm using.  Might not matter, though.

That syntax does work for me on FC4, so probably the issue is GNU
getopt_long versus other implementations (likely, our own port/ code).
I don't think it's relevant though, since John exhibited a failure
even while using the "standard" command line syntax.

The whole thing is more than passing strange.  createlang uses exactly
the same connection code as the other "scripts" binaries, so there's
no obvious reason why it would behave differently.  I concur with the
suggestion to try strace'ing it and see where the behavior starts to
vary from, say, createdb.

            regards, tom lane