"Josh Berkus" <[EMAIL PROTECTED]> writes:
>> 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 go
Tom,
> 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.
OK. I
"Josh Berkus" <[EMAIL PROTECTED]> 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 c
Dado Feigenblatt <[EMAIL PROTECTED]> writes:
> One thing that still isn't clear for me is how to implement access level
> control on a per row basis.
The SQL GRANT/REVOKE stuff doesn't deal with anything finer-grain than
tables. The best way I know to cope with a need for row-level read
access c
Dado,
> Formatting functions? As in formatted output? Could you give an
> example?
Yes. For example, I have a function called:
qf_format_contact_name (VARCHAR, VARCHAR, VARCHAR, VARCHAR)
That produces (depending on data) formatted output like:
Julie Snodgrass
Ms. Keller, Law Clerk
Human Re
Josh Berkus wrote:
> Dado,
>
> Glad to have you with us. Incidentally, in answer to two of your
> remarks:
>
> 1. "current_user", like "current_timestamp" is a built-in SQL92
> function, as opposed to a PostgreSQL function. As such, it does not
> require () and takes no parameters.
Hm
