>>> Really? We are removing usesysid? Seems the admin will no longer be
>>> able to choose the users id, right?
>>
>> Not that this was ever useful.
> Except for re-adding users.
Yes. In theory, the correct answer to that is to add referential
integrity checks that prevent you from dropp
Tom Lane <[EMAIL PROTECTED]> writes:
> No. I'm not sure whether or not I believe the comment about Unix
> accounts; Postgres does not care about Unix accounts, and never has
> to my knowledge. But it has always used the usesysid as owner
> identification for database objects (tables etc). If t
> Kovacs Zoltan <[EMAIL PROTECTED]> writes:
> >> Is it possible that 1060 and 1092 have the same usesysid in pg_shadow?
>
> > Hmmm. That was the problem. Thanks! By the way, could you please define a
> > unique constraint on column 'usesysid' in future in PostgreSQL?
>
> Yup, there should be one
Bruce Momjian writes:
> Really? We are removing usesysid? Seems the admin will no longer be
> able to choose the users id, right?
Not that this was ever useful.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)
> Kovacs Zoltan writes:
>
> > By the way, could you please define a unique constraint on column
> > 'usesysid' in future in PostgreSQL?
>
> The usesysid column will be removed and the oid column will be used
> instead. That one tends to be unique, but an index will still be added.
Really? We
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> The usesysid was originally intended to map pg users to unix accounts.
> I do not see why it should not be possible to map different pg users
> to a single unix account. The above imho stems from an improper use of this
> column which needs to
Kovacs Zoltan writes:
> By the way, could you please define a unique constraint on column
> 'usesysid' in future in PostgreSQL?
The usesysid column will be removed and the oid column will be used
instead. That one tends to be unique, but an index will still be added.
--
Peter Eisentraut [EM
> >> Is it possible that 1060 and 1092 have the same usesysid
> in pg_shadow?
>
> > Hmmm. That was the problem. Thanks! By the way, could you
> please define a
> > unique constraint on column 'usesysid' in future in PostgreSQL?
>
> Yup, there should be one (and one on usename, too). Not sure
Kovacs Zoltan <[EMAIL PROTECTED]> writes:
>> Is it possible that 1060 and 1092 have the same usesysid in pg_shadow?
> Hmmm. That was the problem. Thanks! By the way, could you please define a
> unique constraint on column 'usesysid' in future in PostgreSQL?
Yup, there should be one (and one on u
On Wed, 2 May 2001, Tom Lane wrote:
> Kovacs Zoltan <[EMAIL PROTECTED]> writes:
> > tir=> \c - 1060
> > You are now connected as new user 1060.
> > tir=> select user;
> > current_user
> > --
> > 1092
> > (1 row)
>
> Is it possible that 1060 and 1092 have the same usesysid in pg_sha
Kovacs Zoltan <[EMAIL PROTECTED]> writes:
> tir=> \c - 1060
> You are now connected as new user 1060.
> tir=> select user;
> current_user
> --
> 1092
> (1 row)
Is it possible that 1060 and 1092 have the same usesysid in pg_shadow?
regards, tom lane
This may be a reported bug. 7.1beta4.
I use user names mostly as numbers. E.g. 1050, 1060, 1092.
Sometimes I got strange result when I try to reconnect:
tir=> \c - 1022
You are now connected as new user 1022.
tir=> select user;
current_user
--
1022
(1 row)
(It's OK.)
tir=> \c - 1
12 matches
Mail list logo
