David,

> Dennis has pointed out that mixing the call-with-named-parameter
> interface with call-by-order-of-parameters one would cause confusion,
> and I think it would be OK to disallow this type mixing, so

As we've discussed on IRC, this should be the difference between a FUNCTION 
and a PROCEDURE.  It's about time we implemented a CREATE PROCEDURE statement 
anyway.  

As I see it, the critical difference between FUNCTIONS and PROCEDURES can be 
that:
a) Procedures support named parameter calling but do NOT allow being called in 
the context of a query, and
b) Procedures are not automatically transactional; that is, transactions 
within procedures must/can be explicit.  Among other things, this would allow 
procedures to run maintainence tasks.

This seems to me to be the obvious solution to the Named Parameters vs. 
Overloading conflict, and I'm really puzzled why people keep dismissing it as 
out-of-hand.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Sat, 14 Aug 2004 12:46:23 -0700
Josh Berkus <josh@agliodbs.com>
Re: Calling PL functions with named parameters
Josh Berkus wrote:
> > Dennis has pointed out that mixing the call-with-named-parameter
> > interface with call-by-order-of-parameters one would cause
> > confusion, and I think it would be OK to disallow this type mixing,
> > so
>
> As we've discussed on IRC, this should be the difference between a
> FUNCTION and a PROCEDURE.

Huh?  As far as I can tell, the difference between a function and a 
procedure is precisely that the latter doesn't return a value.  A 
consistent way to specify the parameters of either one would certainly 
be highly desirable.

> b) Procedures are not automatically transactional; that is,
> transactions within procedures must/can be explicit.  Among other
> things, this would allow procedures to run maintainence tasks.

I certainly want all my maintenance tasks to be transactional.  Being 
nontransactional is a fuzzy idea anyway.  You can't really run anything 
without a transaction in PostgreSQL.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Sat, 14 Aug 2004 22:45:03 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: Calling PL functions with named parameters


Peter Eisentraut wrote:

>Josh Berkus wrote:
>  
>
>>>Dennis has pointed out that mixing the call-with-named-parameter
>>>interface with call-by-order-of-parameters one would cause
>>>confusion, and I think it would be OK to disallow this type mixing,
>>>so
>>>      
>>>
>>As we've discussed on IRC, this should be the difference between a
>>FUNCTION and a PROCEDURE.
>>    
>>
>
>Huh?  As far as I can tell, the difference between a function and a 
>procedure is precisely that the latter doesn't return a value.  A 
>consistent way to specify the parameters of either one would certainly 
>be highly desirable.
>
>  
>
>>b) Procedures are not automatically transactional; that is,
>>transactions within procedures must/can be explicit.  Among other
>>things, this would allow procedures to run maintainence tasks.
>>    
>>
>
>I certainly want all my maintenance tasks to be transactional.  Being 
>nontransactional is a fuzzy idea anyway.  You can't really run anything 
>without a transaction in PostgreSQL.
>
>  
>

I think you're right on both counts.

ISTM we need a more strategic discussion of where we want to go with 
procedural code.

some other ideas to consider:
- it would be nice to be able to say PERFORM 'string with plcode' 
language plname;
- OUT / INOUT parameters

I think we need an idea of where we are going with all this stuff, 
rather than approaching the area piecemeal in a way that might preclude 
other decisions we might want to make later.

cheers

andrew

Sat, 14 Aug 2004 17:07:58 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: Calling PL functions with named parameters
Peter Eisentraut <peter_e@gmx.net> writes:
> Josh Berkus wrote:
>> b) Procedures are not automatically transactional; that is,
>> transactions within procedures must/can be explicit.  Among other
>> things, this would allow procedures to run maintainence tasks.

> I certainly want all my maintenance tasks to be transactional.  Being 
> nontransactional is a fuzzy idea anyway.  You can't really run anything 
> without a transaction in PostgreSQL.

Yeah, but the point is that a procedure in these terms could start and
end transactions.  Right now, any process you want to perform that has
to span more than one transaction has to be driven by client-side code.
It *would* be nice to be able to encapsulate such things totally on the
server side.  The actual work would of course all be inside
transactions, but if we could have (some limited amount of) control
logic outside it would be a nice addition.

I agree however with Andrew's nearby point that this is completely
unrelated to named parameters to functions/procedures, or to defaults
for parameters.

			regards, tom lane

Sat, 14 Aug 2004 18:14:54 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Calling PL functions with named parameters 
Tom,

> I agree however with Andrew's nearby point that this is completely
> unrelated to named parameters to functions/procedures, or to defaults
> for parameters.

I think that was Peter's point, not Andrew's.    Andrew agreed with me.

I do think, though, that we should hammer out the parameters, functions, 
procedures, etc. "master plan" before anyone gets further coding them, if 
people are up for it.

Tom, just to be perfectly clear about why I see Procedures as a way of 
resolving parameter ambiguity, my idea is that:
FUNCTIONS will support overloading but will not support named parameter 
calling;
PROCEDURES will support named parameter calling but not support overloading.

This resolves the ambiguity.   Particularly, I'm concerned about adding any 
more code to the evaluation of a function call, out of fear that it will have 
a significant performance impact due to increased time to evaluate built-in 
functions.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Mon, 16 Aug 2004 09:43:28 -0700
Josh Berkus <josh@agliodbs.com>
Re: Calling PL functions with named parameters
Josh Berkus <josh@agliodbs.com> writes:
> Tom, just to be perfectly clear about why I see Procedures as a way of 
> resolving parameter ambiguity, my idea is that:
> FUNCTIONS will support overloading but will not support named parameter 
> calling;
> PROCEDURES will support named parameter calling but not support overloading.

Understood, but this seems like a bad design to me, because it's
non-orthogonal.

> Particularly, I'm concerned about adding any more code to the
> evaluation of a function call, out of fear that it will have a
> significant performance impact due to increased time to evaluate
> built-in functions.

I think that named params would have no significant extra cost *when not
used*, so I'm not sure the above concern is a big deal.  (I do worry
about the cost implications of defaultable parameters, however, as that
seems likely to expand the search space for a matching function quite a
bit.)

			regards, tom lane

Mon, 16 Aug 2004 12:51:21 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Calling PL functions with named parameters 
Tom,

> Understood, but this seems like a bad design to me, because it's
> non-orthogonal.

Or just a natural consequence of our having loaded Functions down with all of 
the functionality usually assigned to Procedures over the years.

> I think that named params would have no significant extra cost *when not
> used*, so I'm not sure the above concern is a big deal.  (I do worry
> about the cost implications of defaultable parameters, however, as that
> seems likely to expand the search space for a matching function quite a
> bit.)

Well, since default params is one of the critical reasons to use named param 
calling in the first place, I think this is a significant concern.

I'm also not looking forward to all of the "help" e-mails we'll get to 
PGSQL-SQL in response to: "Your function cannot be created as specified due 
to a namespace conflict." ... particularly if this happens during database 
reload as a result of new functions in Template1.

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Mon, 16 Aug 2004 16:00:21 -0700
Josh Berkus <josh@agliodbs.com>
Re: Calling PL functions with named parameters