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 ...

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

Reply via email to