> And I have still a question:
> How to remove privileges of the nonexistent (removed) user?
I'm not sure it is even desirable?
There are 2 differents concepts:
- logins with a user name, password...
- sysids which is really an int.
a login must have a sysid, but a sysid may or may not corres
little example of generating usesysid
create user test sysid 2147483647;
CREATE USER
create user test1;
CREATE USER
select * from pg_shadow;
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd |
valuntil | useconfig
--+-+-+--+--
Dear Tom,
I was thinking that any integer attribute of any tuple in a shared
relation would be ok to store a sequence value.
Certainly not --- when there are multiple versions of the tuple because
of MVCC rules, which do you use?
I understand you concern, but I think the troubles depends on how the
Fabien COELHO <[EMAIL PROTECTED]> writes:
> I was thinking that any integer attribute of any tuple in a shared
> relation would be ok to store a sequence value.
Certainly not --- when there are multiple versions of the tuple because
of MVCC rules, which do you use?
regard
Dear Tom,
The "clean" way to handle this would be to extend the bootstrap command
parser to accept a command along the lines of CREATE [SHARED] SEQUENCE
and then add a file in src/include/catalog that defines the shared
user-id-generator sequence. (Look at how pg_shadow is created for
precedent.)
Fabien COELHO <[EMAIL PROTECTED]> writes:
> So the only problem is to implement system-wide "cluster" sequences...
We certainly can't extend the regular CREATE SEQUENCE command this way;
you can't create shared objects after initdb.
The "clean" way to handle this would be to extend the bootstrap
On Tue, Jun 08, 2004 at 05:27:31PM +0200, Fabien COELHO wrote:
> From a practical point of view, I wish I could download all messages from
> this thread so as to do the reading in my mail user agent. Does not seem
> possible from the web interface I found.
No, there is no interface to get the m
Dear Tom.
(I have some vague recollection that we discussed how to do that during
the last go-round --- if you want to work on this, it'd be a good idea
to look in the archives first.)
Ok. I found a thread initiated by you in january 2003. I read it quickly.
From a practical point of view, I wish
Fabien COELHO <[EMAIL PROTECTED]> writes:
> The actual simple fix would be that user ids should NOT be reused by
> default. The problem is that I don't think the already used userids are
> kept anywhere, even as a sequence.
In the last discussion of this issue, I think we had agreed in principle
I just want the system to remove the 102, since it is of no use.
I understood that.
As I said, I haven't thought about it in-depth, but keeping the permissions
with the numeric user is a bad idea.
It is only a bad idea if the same numerical user id is reused. If not,
this is not really a problem.
Hi,
since the dropped user is very unlikely to be resurrected, the correct
answer would be to remove all dangling permissions on the existing
objects. Using a sequence would only clutter the system with unused
grants.
What about ownership? would that mean you want to delete the object?
Since DR
Hello Martin,
Bug reference: 1161
Logged by: Martin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: Linux
Description:User permissions are kept, even if user is dropped
Details:
dropping and creating a user will keep the *old* permission on ob
The following bug has been logged online:
Bug reference: 1161
Logged by: Martin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: Linux
Description:User permissions are kept, even if user is dropped
Details:
Hi,
dropping and creating a
13 matches
Mail list logo
