Re: WITH SYSID dropped

From: "Dr(dot) Ernst Molitor" <molitor(at)uni-bonn(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WITH SYSID dropped
Date: 2006-11-06 10:35:52
Message-ID: 200611061135.52588.molitor@uni-bonn.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Stefan Kaltenbrunner,

dear PostgreSQL gurus,

current_user returns a "name" (currently, 64 bytes of data); I felt it would
be contrary to good database practice to repetitiously include (up to) 64
bytes of data in each and every row of each and every table instead of making
use of what relational databases are about and storing just enough data
(e.g., the usesysid) to make the relation clear.

My assumption was that the PostgreSQL extension to the standard language
(the "WITH SYSID" option of the CREATE USER command, which in itself is still
included in the grammar to allow reading dumps created with pre-8.2.x
versions of PostgreSQL) was here to stay.

I stand up to my wrong decision - it's just my fault - but still hope for a
hint on how to minimize its consequences on my applications (screenshots of
one of them are at http://mibi03.meb.uni-bonn.de/demo/en/ ). Maybe I face no
better option than to store the old database's usesysid's and the
corresponding user names in a table before migrating to 8.2.x and live with a
break (or, for future updates, with some breaks ...) in the
usename-usesysid-relation.

Best wishes and regards,

Ernst

On Sunday, November 5th, 2006, 14:52 Stefan Kaltenbrunner wrote
> Dr. Ernst Molitor wrote:
> > Dear PostgreSQL gurus,
> >
> >
> > The procedure still works, but due to the dropping of "WITH SYSID",
> > moving the data to a new PostgreSQL installation causes headaches. After
> > all, the access to the information about who has changed what is
> > expected to stay.
>
> maybe I'm missing something simple - but why are you not using
> current_user/session_user
> (http://www.postgresql.org/docs/current/interactive/functions-info.html)
> for that task - that seems much less error-prone then using an arbitrary
> number to reference a given database role ...

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2006-11-06 14:12:32 Re: Indicate disabled triggers in \d
Previous Message Dave Page 2006-11-06 09:02:08 Re: adminpack and pg_catalog