Re: has_table_priviledge

On Thu, 24 Apr 2003, Tom Lane wrote:

> Ah. I see it too on 7.2. It looks like the 7.2 parser is choosing
> has_table_privilege(name, oid, text) in preference to
> has_table_privilege(name, name, text). I can get it to work on 7.2 by
> putting in an explicit cast, ie, making the constraint read
> constraint c check
> (has_table_privilege(user, relname::name, 'update'))

thanks alot tom - that did it for me. i'm really glad to have that solved
since i was otherwise going to have to do it at the application layer which
felt hackish.

in case you hadn't already guessed, i was putting together a advisory locking
scheme for certain classes of tables (bi-temporal ones), such that transient
processes could obtain a lock on one invocation, but release it in another.
AFAIK there is no way to do this with the normal locking facilities since any
lock expires when the transaction/session ends (guess you could have a lock
daemon...). anyhow, this facility allows things like cgi's to carry locks
across processes. seems like others would have come up against this problem
before...

> Probably the reason 7.3 doesn't misbehave is that its function is declared
> has_table_privilege(name, text, text). That affects the decision because
> 'text' is a preferred type and 'name' isn't.

i'll upgrade ASAP.

thanks again for the help.

-a

--
====================================
| Ara Howard
| NOAA Forecast Systems Laboratory
| Information and Technology Services
| Data Systems Group
| R/FST 325 Broadway
| Boulder, CO 80305-3328
| Email: ara(dot)t(dot)howard(at)fsl(dot)noaa(dot)gov
| Phone: 303-497-7238
| Fax: 303-497-7259
====================================