On 1/03/2010 9:38 PM, Richard Huxton wrote:
On 01/03/10 12:16, rawi wrote:
Not quite the way you suggest. You could build a series of views with
the WHERE conditions built in to them, and grant permissions on those
though.
Thank you very much for your help.
Unfortunately is this not what I
Richard Huxton wrote:
>
> You could write a set-returning function that takes either:
> 1. A list of conditions
> 2. The text for a WHERE clause
> If it gets no conditions or a blank string, it returns nothing.
> You will need to create the function with SECURITY DEFINER permissions,
>
That's
On 01/03/10 12:16, rawi wrote:
Not quite the way you suggest. You could build a series of views with
the WHERE conditions built in to them, and grant permissions on those
though.
Thank you very much for your help.
Unfortunately is this not what I hoped...
The permissions will be granted dyna
> Not quite the way you suggest. You could build a series of views with
> the WHERE conditions built in to them, and grant permissions on those
> though.
Thank you very much for your help.
Unfortunately is this not what I hoped...
The permissions will be granted dynamic by the application out
On 01/03/10 10:07, rawi wrote:
But - for the case, that an application-programmer or even I (tired, middle
in the night) forget to program the insertion of the needed limiting WHERE
condition - it would be great to have some sort of rule ON SELECT, so a
SELECT without WHERE on the flags would ret
Hi
please help me with the following scenario:
I'd gladly have all persons (contacts, customers, staff etc) in one table
"people" with some distinctive flags.
My reason for this, is that simple contacts could become customers or even
staff, staff members could be in the same time also customers
