From: Stephen Frost on
* Magnus Hagander (magnus(a)hagander.net) wrote:
> I think that's a good idea. Attached is a patch that implements this (I
> think - haven't messed around in that area of the code before). Thoughts?

Cool, thanks!

My only comment is that you should probably stick to one 'zero'
convention- either '!canlogin' or 'canlogin == 0'. I prefer the former,
but the inconsistancy in a single patch is kind of odd. I'm not sure if
there's an overall PG preference.

Thanks,

Stephen
From: Heikki Linnakangas on
Magnus Hagander wrote:
> On Sun, Oct 14, 2007 at 06:16:04PM -0400, Stephen Frost wrote:
>> * Tom Lane (tgl(a)sss.pgh.pa.us) wrote:
>>>> Stephen Frost <sfrost(a)snowman.net> writes:
>>>>> I wonder if the OP was unhappy because he created a role w/ a pw and
>>>>> then couldn't figure out why the user couldn't log in?
>>>> Hm, maybe. In that case just not filtering the entry out of the flat
>>>> file would be good enough.
>>> I've confirmed the confusing behavior in CVS HEAD. With password auth
>>> selected in pg_hba.conf:
>> [...]
>>> Should we just do this, or is it worth working harder?
>> I certainly like this. Honestly, I'd also like the warning when doing a
>> 'create role'/'alter role' that sets/changes the pw on an account that
>> doesn't have 'rolcanlogin'. Much better to have me notice that I goof'd
>> the command and fix it before telling the user 'go ahead and log in'
>> than to have the user complain that it's not working. :)
>>
>> Just my 2c.
>
> I think that's a good idea. Attached is a patch that implements this (I
> think - haven't messed around in that area of the code before). Thoughts?

Is WARNING an appropriate level for this? I think NOTICE is enough, it's
not like something bad is going to happen if you do that, it just means
that you've likely screwed up.

There's legitimate use for creating a role with NOLOGIN and a password.
Maybe you're going to give login privilege later on. It wouldn't be nice
to get WARNINGs in that case, even NOTICEs would be sligthly annoying.

Note that per-role guc variables will also have no effect on a role with
no login privilege. How about connection limit, is that inherited?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

From: Tom Lane on
Heikki Linnakangas <heikki(a)enterprisedb.com> writes:
> There's legitimate use for creating a role with NOLOGIN and a password.

If we think that, then we shouldn't have a message at all.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

From: Stephen Frost on
* Tom Lane (tgl(a)sss.pgh.pa.us) wrote:
> Heikki Linnakangas <heikki(a)enterprisedb.com> writes:
> > There's legitimate use for creating a role with NOLOGIN and a password.
>
> If we think that, then we shouldn't have a message at all.

I'm not sure I agree with that. I don't agree that there's really a
legitimate use for creating a role w/ NOLOGIN and a password either, for
that matter. A 'NOTICE' level message would be fine with me. We have
NOTICE messages for when we create an index for a PK. I find a message
about an entirely unexpected and unworkable configuration alot more
useful than those.

Thanks,

Stephen
From: Dave Page on
Stephen Frost wrote:
> * Tom Lane (tgl(a)sss.pgh.pa.us) wrote:
>> Heikki Linnakangas <heikki(a)enterprisedb.com> writes:
>>> There's legitimate use for creating a role with NOLOGIN and a password.
>> If we think that, then we shouldn't have a message at all.
>
> I'm not sure I agree with that. I don't agree that there's really a
> legitimate use for creating a role w/ NOLOGIN and a password either, for
> that matter.

Preparing a new user account prior to an employee starting? In my last
post we would do that regularly - setup all the accounts etc for the new
user, but disable them all until the start date.

/D

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match