From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | ahoward <ahoward(at)fsl(dot)noaa(dot)gov> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: has_table_priviledge |
Date: | 2003-04-24 23:38:54 |
Message-ID: | 3514.1051227534@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
ahoward <ahoward(at)fsl(dot)noaa(dot)gov> writes:
> On Thu, 24 Apr 2003, Tom Lane wrote:
>> It does work, for me. What PG version are you using, exactly?
> PostgreSQL 7.2 on i686-pc-linux-gnu, compiled by GCC 2.96
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'))
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-04-24 23:48:29 | Re: Factoring where clauses through UNIONS take 2 |
Previous Message | Josh Berkus | 2003-04-24 23:29:05 | Re: [NOVICE] ODBC & Access [Try 2] |