> Bruce,
>
> 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 see pg_proc has "pronargs" and "proargtypes" columns, is this
> not enough to ensure that the correct procedure is called?
>
> Or am I off at a tangent again!!
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.
We can put it back to the old code, or move everything to use only an
oid, with no name, or we can somehow allow the user to supply the
pg_proc.proname, and the argument types, and do a match that way. We
could allow just the proname if there is only one entry with that
proname. (Sequtial scan required, but not too bad. We could even use
the existing index. It is not done that much.) If it is not unique, we
would require the oid.
I hope there is some good solution.
The code currently supports input of oid, or proname_oid, and outputs
proname_oid.
--
Bruce Momjian | maillist@candle.pha.pa.us
830 Blythe Avenue | http://www.op.net/~candle
Drexel Hill, Pennsylvania 19026 | (610) 353-9879(w)
+ If your life is a hard drive, | (610) 853-3000(h)
+ Christ can be your backup. |
