Niclas,
> OK, I was beginning to suspect that but I couldn't find that stated,
> explicitly or imlicitly, anywhere in the documentation.
Well, it's a truism of SQL scripting languages in general that variables can
substitute for constants but not for objects. So I guess that people
assumed that it didn't need to be stated -- like many other things that trip
up newbies <grin>. I've *got* to get that faq engine up and running ...
> I had problems running this at first (the error messages that you get in
> sql isn't that enlightening always...). But I finally figured out that one
> has to make two small changes to make it work (which was a good exercise
> :-):
Sorry. Didn't check for typos.
> Well we thought that the oid was a good way to refer to tables uniquely,
> tables that we don't know the name of initially. I know that one is
> explicitly discouraged to use oid's as unique identifiers as the four byte
> number can hit the ceiling and start all over again and thus not making the
> oid a unique identifier. But we know that for our purpose this will not
> happen anyway as the number of tables we are handling in this context is
> limited. Is that a bad idea?
OIDs are actually a decent unique identifier for tables (but not for rows).
However, you'll find that the usefulness of that OID in postgres is limited;
pg won't, for example, accept the OID in place of the table name. But if
your middleware needs a numerical table id -- why not? The info you need is
in the pg_class table; see the online docs about system catelogs.
The one thing I'll caution you about is that those OIDs will change on
backup/restore of your database. So your app should be prepared to reload
all of the oid-name correspondences on database reload.
--
Josh Berkus
Aglio Database Solutions
San Francisco
