Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Ub6Bq-0007DW-QP for pgsql-docs@arkaria.postgresql.org; Sat, 11 May 2013 09:34:07 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1Ub6Bq-0006zx-4A for pgsql-docs@arkaria.postgresql.org; Sat, 11 May 2013 09:34:06 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Ub6Bn-0006zo-Qh for pgsql-docs@postgresql.org; Sat, 11 May 2013 09:34:04 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Ub6Bk-0001Md-0y for pgsql-docs@postgresql.org; Sat, 11 May 2013 09:34:03 +0000 Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5E78B2072F; Sat, 11 May 2013 05:33:58 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 11 May 2013 05:33:58 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.co.uk; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type; s=mesmtp; bh=oL72pp1rQ+25s3ODiViF/D6V nPQ=; b=DzVtMQYxkccFrHZ/ADuAJXxcxWqaxnssmIFtVx1+78EiIbRrjz/gi/Ey hWtNHBRN1CcTWYChlrm8gzzGlVoIzSw4Zquo5swgLhlYAMyP5QSOaUV/+5njWo66 /Y30tT8j1/IWvEaU7t95n/hE/LiFM1Mo87kOVFHwEAyPGb48DnM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type; s=smtpout; bh=oL72 pp1rQ+25s3ODiViF/D6VnPQ=; b=krcTQoicsvvtYP3a5ygWz0MO8dqDHHBFAO4n P9/4i9Umet4VzQnKYYXJCjkXB+2eHIuOw5x3llbyse/pxi7zgGmZXDqIjhksxEPW FCed1t22nSfFh+/dJZbcc/kTdSCba7TJmn0CPd2mSyuawGJFtGibFx6jpAqvEG2H 5OdzC3E= X-Sasl-enc: d8ze4z6HuJBRJaR30VCSqJa9Dew/jvD5nZH5x8KTCCgm 1368264837 Received: from [192.168.11.21] (unknown [78.146.152.197]) by mail.messagingengine.com (Postfix) with ESMTPA id 70EAEC8000A; Sat, 11 May 2013 05:33:57 -0400 (EDT) Message-ID: <518E1083.7030402@fastmail.co.uk> Date: Sat, 11 May 2013 10:33:55 +0100 From: Sian Mountbatten User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Erwin Brandstetter , pgsql-docs@postgresql.org Subject: Re: Reference function arguments by name References: <518C0B2B.9040909@falter.at> <518DFDAC.2060909@fastmail.co.uk> <518DFF3E.90701@falter.at> In-Reply-To: <518DFF3E.90701@falter.at> Content-Type: multipart/alternative; boundary="------------000608080403030308060407" X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org This is a multi-part message in MIME format. --------------000608080403030308060407 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2013-05-11 09:20, Erwin Brandstetter wrote: > > On 11.05.2013 10:13, Sian Mountbatten wrote: >> On 2013-05-09 21:46, Erwin Brandstetter wrote: >>> Hi! >>> >>> The manual says here: >>> http://www.postgresql.org/docs/current/interactive/sql-createfunction.html >>> http://www.postgresql.org/docs/devel/static/sql-createfunction.html >>> >>>> argname >>>> >>>> The name of an argument. Some languages (currently only >>>> PL/pgSQL) let you use the name in the function body. For other >>>> languages the name of an input argument is just extra >>>> documentation, so far as the function itself is concerned; but >>>> you can use input argument names when calling a function to >>>> improve readability (see Section 4.3 >>>> ). >>>> In any case, the name of an output argument is significant, >>>> because it defines the column name in the result row type. (If >>>> you omit the name for an output argument, the system will >>>> choose a default column name.) >>>> >>> >>> This has changed in version 9.2. SQL functions can reference the >>> name. Ergo: >>> >>> s /(currently only PL/pgSQL) / (currently only PL/pgSQL and SQL) >>> >>> >>> I tested it and it's /correctly /documented here: >>> http://www.postgresql.org/docs/current/interactive/xfunc-sql.html#XFUNC-SQL-FUNCTION-ARGUMENTS >>> >>> > Arguments of a SQL function can be referenced in the function body >>> using either names or numbers. >>> >>> >>> Regards >>> Erwin >> It looks strongly that you people are of the opinion that "the code >> documents >> itself". That is a myth produced by lazy software developers who >> cannot document >> their code properly. You ought to be using Cweb for C code. Have a >> look at >> the code for SQLite to see how comments in C can be used to provide >> decent >> documentation >> >> Fortunately, I do not use C. I prefer a HIGH-level language :-) > > This reply seems unrelated. > > Regards > Erwin The point is that documentation of the code always takes 2nd place. Why argue about readability when the only help you give to anybody who is unfortunate enough to have to maintain your software are names of variables? It doesn't matter a damn whether you put names in or out of a function. What matters is what help do you give your hapless maintainers? Sincerely -- Sian Mountbatten Algol 68 Specialist --------------000608080403030308060407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 2013-05-11 09:20, Erwin Brandstetter wrote:

On 11.05.2013 10:13, Sian Mountbatten wrote:
On 2013-05-09 21:46, Erwin Brandstetter wrote:
Hi!

The manual says here:
http://www.postgresql.org/docs/current/interactive/sql-createfunction.html
http://www.postgresql.org/docs/devel/static/sql-createfunction.html
argname

The name of an argument. Some languages (currently only PL/pgSQL) let you use the name in the function body. For other languages the name of an input argument is just extra documentation, so far as the function itself is concerned; but you can use input argument names when calling a function to improve readability (see Section 4.3). In any case, the name of an output argument is significant, because it defines the column name in the result row type. (If you omit the name for an output argument, the system will choose a default column name.)


This has changed in version 9.2. SQL functions can reference the name. Ergo:

s /(currently only PL/pgSQL) / (currently only PL/pgSQL and SQL)


I tested it and it's correctly documented here:
http://www.postgresql.org/docs/current/interactive/xfunc-sql.html#XFUNC-SQL-FUNCTION-ARGUMENTS

> Arguments of a SQL function can be referenced in the function body using either names or numbers.


Regards
Erwin
It looks strongly that you people are of the opinion that "the code documents
itself". That is a myth produced by lazy software developers who cannot document
their code properly. You ought to be using Cweb for C code. Have a look at
the code for SQLite to see how comments in C can be used to provide decent
documentation

Fortunately, I do not use C. I prefer a HIGH-level language :-)

This reply seems unrelated.

Regards
Erwin
The point is that documentation of the code always takes 2nd place. Why
argue about readability when the only help you give to anybody who is
unfortunate enough to have to maintain your software are names of variables?
It doesn't matter a damn whether you put names in or out of a function.
What matters is what help do you give your hapless maintainers?

Sincerely
-- 
Sian Mountbatten
Algol 68 Specialist
--------------000608080403030308060407--