Re: Function parameter names

From: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Function parameter names
Date: 2003-11-23 18:18:46
Message-ID: Pine.LNX.4.44.0311231907050.29118-100000@zigo.dhs.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dennis Bjorklund 2003-11-23 18:23:12 Re: Function parameter names
Previous Message Peter Eisentraut 2003-11-23 18:17:19 initdb mkdir_p() doesn't work