* Magnus Hagander (magnus@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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHFiO8rzgMPqB3kigRAvz9AJ40ZW2Ag/4iX5wQc8hNcDCwW1mTOACdG5b7
YurBduIuUpjL67/D8TOTaRg=
=PvDK
-----END PGP SIGNATURE-----

Magnus Hagander wrote:
> On Sun, Oct 14, 2007 at 06:16:04PM -0400, Stephen Frost wrote:
>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>>>> Stephen Frost <sfrost@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

Heikki Linnakangas <heikki@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

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Heikki Linnakangas <heikki@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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHFivNrzgMPqB3kigRAienAJ0avFOtv2N8nUZjI+xbUl E5VoKhKwCfXZor
y/Q4ReYIfYV4Qxj0NYaSIAQ=
=zygU
-----END PGP SIGNATURE-----

Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Heikki Linnakangas <heikki@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

On Wed, Oct 17, 2007 at 05:09:25PM +0100, Dave Page wrote:
> Stephen Frost wrote:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> Heikki Linnakangas <heikki@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.

Yeah, but did you actually set a password for them?

We do that all the time here, but we don't set the passwords until they
show up.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Wed, Oct 17, 2007 at 11:27:10AM -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki@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.

At least if we think it's more than a very narrow legitimate use, compared
to the number of ppl making the mistake.

I agree with making it a NOTICE instead of WARNING though.

//Magnus

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

Magnus Hagander wrote:
> On Wed, Oct 17, 2007 at 05:09:25PM +0100, Dave Page wrote:
>> Stephen Frost wrote:
>>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>>>> Heikki Linnakangas <heikki@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.
>
> Yeah, but did you actually set a password for them?

Yeah, then have them change them all during day 1 IT induction training.

We had a much smaller team that I know you do, and the staff that would
do the account setup would often be busy first thing on Monday morning
when new starters might often arrive - so we would just 'flip the
switch' on the pre-configured accounts.

/D


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

Magnus Hagander wrote:
> On Wed, Oct 17, 2007 at 11:27:10AM -0400, Tom Lane wrote:
>> Heikki Linnakangas <heikki@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.
>
> At least if we think it's more than a very narrow legitimate use, compared
> to the number of ppl making the mistake.
>
> I agree with making it a NOTICE instead of WARNING though.

Did we ever come to a conclusion on this or not? I've changed my patch
per the suggestions in the thread, but I've held back on committing it
to hear arguments... Go or no-go?

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Magnus Hagander <magnus@hagander.net> writes:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> At least if we think it's more than a very narrow legitimate use, compared
>> to the number of ppl making the mistake.

> Did we ever come to a conclusion on this or not? I've changed my patch
> per the suggestions in the thread, but I've held back on committing it
> to hear arguments... Go or no-go?

I'm inclined to vote no-go on the message. AFAIR we've only heard the
one complaint about this, so I'm not convinced there's a lot of people
making such a mistake. We did make the logic change to deal with the
underlying problem of a misleading error message after you'd done it,
and I think that might be enough.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org