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
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 |