Re: creating variable views

"Josh Berkus" <josh(at)agliodbs(dot)com> writes:
> All this function does is format output, rather than perform any fancy
> manipulation. I find that the Postgres view optimizer has no trouble
> with such functions.
> More complex functions, like qf_calc_next_invoice_date(VARCHAR) which
> calculates a client's next invoice date based on their invoice interval
> plus certain system variables pretty much kills the view optimizer if I
> do a WHERE on that column, since the optimizer doesn't know what to
> expect from the function.

I don't understand the distinction you're trying to make here. In
general, a view column that is implemented as a function will give the
optimizer headaches if you refer to it in WHERE --- the simplicity or
complexity of the function has got nothing to do with that AFAICS.

> That was an example of the sort of sweeping user access change one might
> be asked to implement. For example, you might set up the system at the
> start so that only the Sysadmin can "void" (cancel) financial
> transactions for security purposes. However, changes in your company's
> business policies in 3 months may dictate that the whole accounting
> dept. needs to be able to void. Using SQL DB security, this can be a
> serious headache, as opposed to a single update with an interface-based
> system.

Seems to me that such a change could be trivial, or a serious headache,
with *either* SQL GRANT-based security or application-based security.
The critical factor is going to be whether you represented the "voiding"
access privilege separately from the other special privileges of the
sysadmin. I don't see how one implementation is going to encourage you
to have that foresight better than the other one would.

regards, tom lane