Answering in inverse order: Since the name is the discovery criteria, function overloading is not supported in this interface. It's possible to define a diffe

Answering in inverse order: Since the name is the discovery criteria, function overloading is not supported in this interface. It's possible to define a different one, but the idea here is that the stored procedures should be discoverable based on name. So we have test cases that raise errors when functions are overloaded that we don't know should be. So in answer to your last question, behavior is undefined, and such a condition will trigger failures in our database unit tests. On the other side, the reason to enforce an explicit mapping is because it isn't clear how much you really want to trust the client to execute any function in the database at all. An earlier version used AUTOLOAD to map these methods in directly so no middleware changes would be necessary. We abandoned that approach in part because of concerns it could be abused. So the issue isn't what can you do with my framework that you can't do with your framework but actually the other way around. Do I want to whitelist or blacklist stored procedures? Whitelisting seems safer. A future version will probably use Module::Compile to build mappings from the database, but we haven't defined interfaces sufficiently to make this happen. However one idea is to tie Perl classes to PostgreSQL complex data types, and grab functions which return those complex types. Since all procedures are supposed to return useful data (even delete operations might return the deleted row), then this might work. Again that's in the design phase. Edit: It occurs to me that if the return type and the function name become the discovery criteria, then two functions could have the same name but different args as long as they have different return types.