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.t.howard@fsl.noaa.gov
  | Phone:  303-497-7238
  | Fax:    303-497-7259
  ====================================