The major problem with this approach is that we're not victim of a PG vs. Oracle problem here, but rather an Oracle vs. SQL92 problem.
So hacking a solution like this into our PG port will simply leave the problem lingering for those who port to the next SQL92-compliant database.
(user operators and a stored, programmatic language are both non-SQL92 PG extensions).
Much better would be an approach that made the Oracle kludge "special" rather than the code running in the standards-compliant RDBMS. In other words, it would be preferable to hack the Oracle queries and/or the surrounding Tcl scripts so the PG code runs with 100% standard SQL92.
Then these same PG queries will work perfectly, without change, in other SQL92-compliant RDBMS engines.
