Re: Function parameter names - Mailing list pgsql-hackers

From Dennis Bjorklund
Subject Re: Function parameter names
Date
Msg-id Pine.LNX.4.44.0311231907050.29118-100000@zigo.dhs.org
Whole thread Raw
In response to Re: Function parameter names  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Function parameter names  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, 23 Nov 2003, Peter Eisentraut wrote:

> How will that work in arbitrary procedural languages?

It is passed along to the handler of the language, and if the language
wants, it can insert these into its environment before execution. I plan
to look at the languages pgsql and sql, but any other language can of 
course use it once it's implemented.

It will still work if you do not give argument names of course.

> > What is the reason for the oidvector to be it's own type instead of a
> > oid[]?
> 
> An oidvector is fixed length, so you can access it via a C struct, like
> pgprocval->proargtypes[2].  With a normal array, things get much more
> complicated, and that cost would be fairly large if you want to resolve
> the argument types of function calls.

And the cost will be fairly large for named parameters as well then. On 
the other hand, if one omits the parameter names one would get almost the 
same speed as before (an extra test is needed to see if we have any 
parameter names that needs to be setup before the language handler is 
called).

> Second, it would use up a fixed length of NAMEDATALEN * FUNC_MAX_ARGS
> (currently 1024 bytes) in every pg_proc row.

Yea, this I of course knew and was not happy about.

> In this case, a regular name[] would be more suitable.
> Just be sure to put it after all the fixed-length fields.

I'll take a look at name[] then as the first try.

-- 
/Dennis



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: initdb mkdir_p() doesn't work
Next
From: Dennis Bjorklund
Date:
Subject: Re: Function parameter names