"Craig Ringer" wrote in message
news:4c33dc32.7080...@postnewspapers.com.au...
> On 06/07/10 17:47, Davor J. wrote:
>> Thanks Craig.
>>
>> I still find it a bit awkward that we have to use "priv check function"-s
>> because we can't define triggers on or reference to system tables. I
>> think
>>
On 06/07/10 17:47, Davor J. wrote:
> Thanks Craig.
>
> I still find it a bit awkward that we have to use "priv check function"-s
> because we can't define triggers on or reference to system tables. I think
> that allowing it would significantly extend Postgres possibilities.
Certainly being abl
Thanks Craig.
I still find it a bit awkward that we have to use "priv check function"-s
because we can't define triggers on or reference to system tables. I think
that allowing it would significantly extend Postgres possibilities.
>From a quick google it seems that triggers on system tables is
On 04/07/10 21:43, Davor J. wrote:
> PS using inheritance in this scenario is problematic.
Yep. Just one issue is that roles are cluster-wide, whereas tables are
visible only inside a single database.
I generally use the role mechanism as-is, granting users access to roles
that control particul
Several times I wanted to "extend" some of the postgres objects, like roles
or functions. For example, sometimes you want to add extra attributes to
roles, which are application dependent. Or sometimes you want to store
functions and reference them in your custom tables, without losing
referent
