> > What I can't see from the postings, is what incident or problem
> > prompted the change.
> > Was there test or query that failed because it chose the wrong
> > procedure?
> > Do you have an example which failed with the old code and needed
> > the changes to make it work?
> I found that the regprocin routine was doing a sequential scan of
> pg_proc, looking for a function matching the supplied name, and using
> the first matching entry of pg_proc.proname.
> Two problems: You can't use the system cache to look up the pg_proc
> value, because the cache only does unique lookups. Second, we have
> many functions that have multiple entries in the pg_proc table with
> the same name, but different arguments, so it was not really accurate.
> We certainly need to change what I have done, but I am not sure how to
> change it.
I'm sorry Bruce for not keeping up, but could you please send me the old
postings which summarize the symptoms of the problem? And any private
response to Keith which answered his initial questions above?
I understand that the regprocin support routine was apparently not using
enough keys in the pg_proc lookup to find the unique entry match, but
where is regprocin used? I assume that it is support code, but is it
used internally only, or are you using it for some of the psql/pg_dump
construction?
From the code used in the parser to support functions and operators, I
would have guessed that you can define multiple key fields for cache
lookups; do those techniques fail in this case or are they not being
used?
Anyway, I'm concerned about the name mangling and the proximity to the
v6.4 release, and would like to help work out the issues if I can...
- Tom