Received: from maia.hub.org (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id EAECA633F5F
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Fri, 21 Aug 2009 19:03:10 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia,
	port 10024) with ESMTP id 31929-09
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Fri, 21 Aug 2009 22:03:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from phoenix.advel.cz (phoenix.advel.cz [81.0.239.26])
	by mail.postgresql.org (Postfix) with SMTP id 3CCDC633E7B
	for <pgsql-hackers@postgresql.org>;
	Fri, 21 Aug 2009 19:02:59 -0300 (ADT)
Received: (qmail 9577 invoked from network); 22 Aug 2009 00:02:56 +0200
Received: from unknown (HELO ?10.12.0.96?) (88.103.48.48)
	by 192.168.1.50 with SMTP; 22 Aug 2009 00:02:56 +0200
Message-ID: <4A8F1986.3030506@pjmodos.net>
Date: Sat, 22 Aug 2009 00:02:46 +0200
From: Petr Jelinek <pjmodos@pjmodos.net>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Alvaro Herrera <alvherre@commandprompt.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: GRANT ON ALL IN schema
References: <4A86B5D5.6060807@dunslane.net> <4A871F46.1040002@agliodbs.com>
	<5D5ECAE0-F2B0-479B-9594-50AAF18F10ED@hi-media.com>
	<20090815223102.GS5407@samason.me.uk>
	<1250378139.18992.6.camel@vanquo.pezone.net>
	<603c8f070908152051mbd1d706hb0e29f5cfaf2f151@mail.gmail.com>
	<4A87854B.3070707@dunslane.net>
	<1250427428.26280.2.camel@vanquo.pezone.net>
	<395.1250439160@sss.pgh.pa.us> <4A8D9CA0.1040607@pjmodos.net>
	<20090820190604.GK6261@alvh.no-ip.org>
	<3493.1250864810@sss.pgh.pa.us>
In-Reply-To: <3493.1250864810@sss.pgh.pa.us>
Content-Type: multipart/alternative;
	boundary="------------010903090907000202090901"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.598 tagged_above=-10 required=5
	tests=BAYES_00=-2.599, HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 200908/1516
X-Sequence-Number: 144159

This is a multi-part message in MIME format.
--------------010903090907000202090901
Content-Type: text/plain; charset=windows-1250; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane napsal(a):
>> That's really 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.
>>     
>
> +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.
>   

Alright I can do it this way.
However there 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 required info as parameters and "fabricate" 
some of it when compiling inline function. I am unsure which one is the 
preferred way.

-- 
Regards
Petr Jelinek (PJMODOS)


--------------010903090907000202090901
Content-Type: text/html; charset=windows-1250
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1250"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Tom Lane napsal(a):
<blockquote cite="mid:3493.1250864810@sss.pgh.pa.us" type="cite">
  <blockquote type="cite">
    <pre wrap="">That's really 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>
However there 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 required info as parameters and
"fabricate" some of it when compiling inline function. I am unsure
which one is the preferred way.<br>
<pre class="moz-signature" cols="72">-- 
Regards
Petr Jelinek (PJMODOS)</pre>
</body>
</html>

--------------010903090907000202090901--