Re: Calling PL functions with named parameters

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, David Fetter <david(at)fetter(dot)org>
Subject: Re: Calling PL functions with named parameters
Date: 2004-08-16 16:43:28
Message-ID: 200408160943.28826.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-08-16 16:51:21 Re: Calling PL functions with named parameters
Previous Message Bruce Momjian 2004-08-16 16:14:27 Re: Tablespace issues (comment on ,moving indexes)