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>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, 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 23:00:21
Message-ID: 200408161600.21610.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-08-16 23:19:21 Re: pulling projection up in plans
Previous Message Bruce Momjian 2004-08-16 22:59:24 Re: to_char() and negative intervals