Re: Function parameter names

Поиск
Список
Период
Сортировка
От Dennis Bjorklund
Тема Re: Function parameter names
Дата
Msg-id Pine.LNX.4.44.0311231907050.29118-100000@zigo.dhs.org
обсуждение исходный текст
Ответ на Re: Function parameter names  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Function parameter names
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: initdb mkdir_p() doesn't work
Следующее
От: Dennis Bjorklund
Дата:
Сообщение: Re: Function parameter names