Re: First patch proposal

Hi

I am a keen Postgres user and I run my local PUG (JNBPUG in Gauteng,
South Africa), but I have found the idea of contributing on a code
level daunting.

Having read the many warnings along the lines of "It's still on the
todo because it isn't trivial" I have identified what I believe is a
manageble task for my first patch and expect to have the time to
tackle it at the end of the month. I think the proposed changes are
small enough for a first attempt and I don't find anything in the
archives suggesting that the outcome I am proposing was deliberately
avoided.

I am proposing altering psql to raise certain errors and exit before
prompting for a password. These errors would have to be on items which
didn't leak any information, my current list is:
- Does the input file (-f) exist and is it readable
- Do paths to the output files ( -o and -l) exist and are they writable
- Is the host/socket listening (-h)

This is obviously scratching an itch of my own - I end up capturing
passwords and then getting errors from mistyped input files on a
regular basis. I don't think that I'm the only person to have the
problem though (at least I hope not).

Does this sound like a sane, desirable set of changes?

Regards

Alastair "Bell" Turner

Technical Lead
^F5

Alastair Turner <bell(at)ctrlf5(dot)co(dot)za> writes:
> I am proposing altering psql to raise certain errors and exit before
> prompting for a password. These errors would have to be on items which
> didn't leak any information, my current list is:
> - Does the input file (-f) exist and is it readable
> - Do paths to the output files ( -o and -l) exist and are they writable
> - Is the host/socket listening (-h)

You could probably do the first two (not sure how badly you'd have to
contort the logic in psql, but in principle you could do it). I'm not
sure I like/believe the last one though. The prompt for password is
already driven by the server demanding one, isn't it? So you won't get
one if -h is bad. If you're thinking of altering the behavior when -W
is specified, I'd be agin it, because I think the point of that switch
is to ensure predictable behavior, ie that the program will ask for a
password no matter how the server responds or doesn't.

regards, tom lane

2010/10/14 Alastair Turner <bell(at)ctrlf5(dot)co(dot)za>:
> I am proposing altering psql to raise certain errors and exit before
> prompting for a password. These errors would have to be on items which
> didn't leak any information, my current list is:
>  - Does the input file (-f) exist and is it readable
>  - Do paths to the output files ( -o and -l) exist and are they writable
>  - Is the host/socket listening (-h)
>
> This is obviously scratching an itch of my own - I end up capturing
> passwords and then getting errors from mistyped input files on a
> regular basis. I don't think that I'm the only person to have the
> problem though (at least I hope not).
>
> Does this sound like a sane, desirable set of changes?

I think yes. Just for information, did you pick this topic from TODO
list? If so, could you attach links to the entry or to some related
former thread? And in general it is encouraged that you'd better send
one feature per a patch, in order for it to be reviewed and committed
easily, rather than going all the three you mentioned above.

Regards,

--
Hitoshi Harada

On Thu, Oct 14, 2010 at 4:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alastair Turner <bell(at)ctrlf5(dot)co(dot)za> writes:
>> I am proposing altering psql to raise certain errors and exit before
>> prompting for a password. These errors would have to be on items which
>> didn't leak any information, my current list is:
>>  - Does the input file (-f) exist and is it readable
>>  - Do paths to the output files ( -o and -l) exist and are they writable
>>  - Is the host/socket listening (-h)
>
> You could probably do the first two (not sure how badly you'd have to
> contort the logic in psql, but in principle you could do it).  I'm not
> sure I like/believe the last one though.  The prompt for password is
> already driven by the server demanding one, isn't it?  So you won't get
> one if -h is bad.  If you're thinking of altering the behavior when -W
> is specified, I'd be agin it, because I think the point of that switch
> is to ensure predictable behavior, ie that the program will ask for a
> password no matter how the server responds or doesn't.

Thanks for the feedback, I'll keep it to the first two then.

Regards

Bell

Excerpt from Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> - Thu, Oct 14, 2010
at 4:32 PM:
> Just for information, did you pick this topic from TODO
> list? If so, could you attach links to the entry or to some related
> former thread? And in general it is encouraged that you'd better send
> one feature per a patch, in order for it to be reviewed and committed
> easily, rather than going all the three you mentioned above.
>
It isn't a TODO item, or related to any previous thread I could find.
When I'm making the changes I'll bear in mind the preference for
multiple small patches. I have a feeling that the changes would be to
the logic structure and that it wouldn't be possible to separate the
implementation of each check though.

Regards

Bell.

On 14/10/10 15:53, Alastair Turner wrote:
> It isn't a TODO item, or related to any previous thread I could find.
>
It's certainly something I can see a use for. When I'm having a bad
typing day I get annoyed that I find I've made a mistake after I've
typed the password. To me this is a feature that will just make life a
little more pleasant for command line junkies like me.

Regards,

--
Mike Fowler
Registered Linux user: 379787

On 14/10/10 15:53, Alastair Turner wrote:
> It isn't a TODO item, or related to any previous thread I could find.
>

It's certainly something I can see a use for. When I'm having a bad
typing day I get annoyed that I find I've made a mistake after I've
typed the password. To me this is a feature that will just make life a
little more pleasant for command line junkies like me.

Regards,

--
Mike Fowler
Registered Linux user: 379787

NB: Post attmpt two, yesterday's was never delievered to hackers so apologies if Alastair and Hitoshi have seen this message once already.

On Wed, 2010-10-13 at 22:29 +0200, Alastair Turner wrote:

> I am proposing altering psql to raise certain errors and exit before
> prompting for a password. These errors would have to be on items which
> didn't leak any information, my current list is:
> - Does the input file (-f) exist and is it readable
> - Do paths to the output files ( -o and -l) exist and are they writable
> - Is the host/socket listening (-h)
>

I think these are pretty good. The last one might not be as easy as you
think.

Joshua D. Drake

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt