Skip site navigation (1) Skip section navigation (2)

Re: function_name.parameter_name

From: Darren Duncan <darren(at)darrenduncan(dot)net>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: function_name.parameter_name
Date: 2010-09-08 19:17:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bruce Momjian wrote:
> Sergey Konoplev wrote:
>> 1.
>> CREATE FUNCTION func_name(arg_name text) RETURNS integer AS $$
>>     RAISE INFO '%', func_name.arg_name;
>> ...
>> 2.
>> CREATE FUNCTION func_name() RETURNS integer AS $$
>>     var_name text := 'bla';
>>     RAISE INFO '%', func_name.var_name;
>> ...
>> 3.
>> CREATE FUNCTION func_very_very_very_very_long_name() RETURNS integer AS $$
>> << func_alias >>
>>     var_name text := 'bla';
>>     RAISE INFO '%', func_alias.var_name;
>> ...

I suggest that it might be reasonable to introduce a new syntax, that isn't 
already valid for something inside a routine, and use that as a terse way to 
reference the current function and/or its parameters.  This may best be a simple 
constant syntax.

For example, iff it isn't already valid for a qualified name to have a leading 
period/full-stop/radix-marker, then this could be introduced as a valid way to 
refer to the current routine.

Then in the above examples you can say:

   RAISE INFO '%', .arg_name;

   RAISE INFO '%', .var_name;

... without explicitly declaring a func_alias.

In a tangent, you can also use a new constant syntax (unless you have one?) to 
allow a routine to invoke itself without knowing its own name, which could be 
nice in a simple recursive routine.  Maybe ".(arg,arg)" would do it?

I would think this should be non-intrusive and useful and could go in 9.1.

-- Darren Duncan

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2010-09-08 19:27:29
Subject: Re: plan time of MASSIVE partitioning ...
Previous:From: Tom LaneDate: 2010-09-08 19:16:00
Subject: Re: function_name.parameter_name

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group