---------- Original Message -----------
From: "unordained" <unordained_00@...>

> Two additional "solutions":
>
> - Use generators. Set their values to the proper (integer) constants,
> and always
> (always!) call them with gen_id(blah,0). Yes, they'll get messed up if
> someone decides to get their 'next value', and it only works for
> integers ... but at least you'll have dependencies!
>
> - Use procedures. A simple procedure returns a numeric (or other type)
> constant. Comes at the cost of extra procedure call, but you have
> control over who can modify the procedure, or even who can use it
> (admin-only constants?) Also, cached procedures could make changing
> the constant on-the-fly a problem, as not all connections would see
> the same version of the procedure. (See other recent discussion about
> that.) But at least it's a central place to change it.
>
> -Philip

------- End of Original Message -------

Third solution:

- Use UDFs. They can be used a little more conveniently, as scalars, inside SQL
statements (no need for sub-selects or awkward joins.) You can also use them more
easily to assign values (no need for the "returning_values" clause. I'm not sure,
they might also be more usable if you wanted to setup a CHECK constraint, as in
"check(value in (x1(), x2(), x3()))". More trouble to setup and maintain, but
once you've got one working, the rest are easy enough. So long as you don't run
into any UDF/null issues, which with constants, seems unlikely ...

-Philip