Shridhar Daithankar [EMAIL PROTECTED] writes:
I would say keep range of user specified ids and automatically generated ids
exclusive to each other.
No, that won't do. The principal reason why we keep the explicit SYSID
option around at all is so that a DBA can deliberately recreate a user
Shridhar Daithankar [EMAIL PROTECTED] writes:
If this is the idea, I suggest that all user/group transactions be logged. So
that admin can go thr. them to find out what was id of an user at any given
time. Otherwise admin is not likely to keep list of uids handy and in tough
situation,
Bruce Momjian [EMAIL PROTECTED] writes:
The reason I was being cautious is to handle cases where people are
poking in pg_shadow directly.
If they're poking pg_shadow directly, I think it's up to them to avoid
or cope with sysid conflicts (the unique indexes on the table will
prevent the worst
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The reason I was being cautious is to handle cases where people are
poking in pg_shadow directly.
If they're poking pg_shadow directly, I think it's up to them to avoid
or cope with sysid conflicts (the unique indexes on the table
Tom Lane wrote:
Currently, the default sysid assigned to a user or group is computed as
max(sysid)+1. We've seen a couple of complaints now from people who
deleted their newest user, made another user, and found that permissions
from the deleted user carried over to the new one.
It seems
Bruce Momjian [EMAIL PROTECTED] writes:
OK. Do we have many people left upgrading from pg_dump's that COPY into
pg_shadow?
Hm, good point. I had forgotten we ever did that ;-)
It looks like 7.0.* was the last release where pg_dumpall did that.
Is that far enough back?
[ looks further... ]
On Fri, Jan 17, 2003 at 11:38:24AM -0500, Bruce Momjian wrote:
Tom Lane wrote:
A small difficulty is that explicitly-specified sysids could conflict
with sysids generated later by the sequence. We could perhaps fix this
by forcing up the sequence setting to be at least as large as an
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK. Do we have many people left upgrading from pg_dump's that COPY into
pg_shadow?
Hm, good point. I had forgotten we ever did that ;-)
It looks like 7.0.* was the last release where pg_dumpall did that.
Is that far enough back?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
This way, we don't need to bother with
touching the sequence at all during a CREATE USER with explicit sysid.
Well, the problem is that this could still cause the reuse of a deleted
user, no? Wasn't that the problem we were
On Fri, 2003-01-17 at 12:36, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
This way, we don't need to bother with
touching the sequence at all during a CREATE USER with explicit sysid.
Well, the problem is that this could still cause the reuse of a deleted
user, no? Wasn't
Have we decided it's really too difficult to remove all references to a
given sysid when the user is dropped? It seems like we're creating
multiple new problems in an effort to workaround one existing problem.
Robert Treat
On Fri, 2003-01-17 at 12:38, Bruce Momjian wrote:
Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Have we decided it's really too difficult to remove all references to a
given sysid when the user is dropped?
Getting at objects in other databases is considerably less practical
than anything we've discussed here. At a minimum I think it would
require
On Fri, 2003-01-17 at 14:32, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Have we decided it's really too difficult to remove all references to a
given sysid when the user is dropped?
Getting at objects in other databases is considerably less practical
than anything we've
Robert Treat [EMAIL PROTECTED] writes:
On Fri, 2003-01-17 at 14:32, Tom Lane wrote:
Getting at objects in other databases is considerably less practical
than anything we've discussed here.
Perhaps you don't allow the removal unless all databases came up clean.
You can have the db admin go in
Currently, the default sysid assigned to a user or group is computed as
max(sysid)+1. We've seen a couple of complaints now from people who
deleted their newest user, made another user, and found that permissions
from the deleted user carried over to the new one.
It seems to me that the easiest
On 17 Jan 2003 at 1:16, Tom Lane wrote:
Currently, the default sysid assigned to a user or group is computed as
max(sysid)+1. We've seen a couple of complaints now from people who
deleted their newest user, made another user, and found that permissions
from the deleted user carried over to
16 matches
Mail list logo