Joe Conway <[EMAIL PROTECTED]> writes:
> With the current linked list, the function is effectively leaked to the
> end of the session anyway, so I don't think this is any worse. Thoughts?
Don't worry about it now. If a plpgsql function cache entry is
discarded, we leak far more than just the fun
Joe Conway wrote:
Compiles clean, and passes all regression tests. I'll look to update the
docs and regression tests as part of my post freeze array/polymorphic
function cleanup.
Oh, almost forgot. I had one question, seen here in
get_function_by_signature()
+ if (!entry_valid)
+ {
+ plp
Tom Lane wrote:
> Joe Conway wrote:
2) create hash key using a new structure that includes function oid,
return type, and argument types, and use that for direct lookup.
The latter. By the time you pay the price of a hash lookup, a slightly
longer key is nearly free. (Maybe entirely free, since
Tom Lane wrote:
The latter. By the time you pay the price of a hash lookup, a slightly
longer key is nearly free. (Maybe entirely free, since it might produce
better-distributed hash values.)
OK -- I figured that's what you'd say, so I've already started down that
road.
dynahash only supports f
> Do you think it would be better to do
> 1) a hash lookup by function oid to a linked list of different compiled
> versions (for each set of argument/return types)
>-or-
> 2) create hash key using a new structure that includes function oid,
> return type, and argument types, and use that fo
Joe Conway wrote:
Tom Lane wrote:
(It might be time to change the cache lookup into a hashtable instead of
a simple linear list search...)
I could do that if you want, but do you really think it's worth it? How
long does a linked list have to get before a hash table starts to be a
win (this is s
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
The attached patch enables PL/pgSQL functions (but not triggers) to
accept and return polymorphic types. It is careful to return false from
func_up_to_date() if any of the polymorphic types change from
call-to-call.
I don't think you can use
Joe Conway <[EMAIL PROTECTED]> writes:
> The attached patch enables PL/pgSQL functions (but not triggers) to
> accept and return polymorphic types. It is careful to return false from
> func_up_to_date() if any of the polymorphic types change from
> call-to-call.
I don't think you can usefully d
The attached patch enables PL/pgSQL functions (but not triggers) to
accept and return polymorphic types. It is careful to return false from
func_up_to_date() if any of the polymorphic types change from
call-to-call. It also falls back to the pg_proc declared types if the
caller didn't setup the
