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/curre...ions-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