Re: GRANT ON ALL IN schema - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: GRANT ON ALL IN schema
Date
Msg-id 4A8F1986.3030506@pjmodos.net
Whole thread Raw
In response to Re: GRANT ON ALL IN schema  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: GRANT ON ALL IN schema  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane napsal(a): <blockquote cite="mid:3493.1250864810@sss.pgh.pa.us" type="cite"><blockquote type="cite"><pre
wrap="">That'sreally ugly.  It'll cause catalog bloat with every execution.
 
I think it would be acceptable to have a new column in pg_language that
pointed to an anonymous block execute function.  Languages that do not
define this function cannot use this new feature.   </pre></blockquote><pre wrap="">
+1.  The other way would also (presumably) mean invoking the language's
validate procedure, which might well be redundant and in any case would
probably not have exactly the error-reporting behavior one would want.
I think it's better if the language knows it's dealing with an anonymous
block.  You could even imagine the language relaxing its rules a bit,
for instance not requiring an outer BEGIN/END in plpgsql. </pre></blockquote><br /> Alright I can do it this way.<br />
Howeverthere is one question about implementing it in plpgsql. Currently, the compiler reads info directly from heap
tuple,so I either have to write separate compiler for inline functions or change the existing one to accept the
requiredinfo as parameters and "fabricate" some of it when compiling inline function. I am unsure which one is the
preferredway.<br /><pre class="moz-signature" cols="72">-- 
 
Regards
Petr Jelinek (PJMODOS)</pre>

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: SIGUSR1 pingpong between master na autovacum launcher causes crash
Next
From: Tom Lane
Date:
Subject: Re: SIGUSR1 pingpong between master na autovacum launcher causes crash