Dr. Ernst Molitor wrote: > Dear PostgreSQL gurus, > > having read through the thread on the topic cited above, I still think > the change - however well-founded it may be - carries a problem: That of > an upgrade on installations that relied on the statement. > > Currently, I'm preparing to switch a PostgreSQL-8.0.3-installation to > the current PostgreSQL version. The installation makes use of timetravel > and of a one-liner to access the pg_users.usesysid field to keep a > record about who has changed what and when (which, here in Germany, is a > legal requirement if you deal with medical data). With a one-liner, > which is but a wrapper around PostgreSQL's internal GetUserId function, > it has been nothing but creating a function "current_userid" and adding > a trigger to each table that should be able to record the user who > commited or changed the row. Obviously, the whole job could be performed > at database level. > > 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 ... Stefan ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
