I am getting closer but ... > > > Sure. What I prefer to do is to allow for a (cacheable) lookup on the > > > basis of some criteria, either: > > > 1. Function name or > > > 2. Function name and first argument type > > > > > > This assumes that whichever discovery criteria you are using leads to > > > uniquely identifying a function. > > > > > > Then from the argument list, I know the names and types of the arguments, > > > and the service locator can map them in. This means: > > > > > > 1. You can expose an API which calls arguments by name rather than just > > > position, and > > > 2. You can add arguments of different types without breaking things as > > > long as it is agreed that unknown arguments are passed in as NULL. > > Ok. Two ways of doing this based on different discovery criteria.. The > first would be: > > CREATE FUNCTION person_save(in_id int, in_first_name text, in_last_name > text, in_date_of_birth date) > RETURNS person LANGUAGE ... as $$ ... $$; > > Then you have a service locator
It runs as a library which helps the program decide how to do the call. Currently it looks in the system catalogs but you still have the ordinal syntax too.
One minor issue currently is that object properties override named arguments when it should probably be the other way around.
I have a composite type mapper also on CPAN but it is far less mature and the documentation is not really very good yet.
The basic approach is:
1. Loop up the argument names
2. Strop any in_ off the beginning (in_ being a convention used to avoid name collision with underlying columns)
3. Map those back in as named arguments or object properties.
4. Any unknown inputs, we supply NULL (UNKNOWN) to.
Thanks, Karsten > "I have a person object and want to call person_save." It then looks up the function argument names and > calls it something like this: > > SELECT * FROM person_save(?, ?, ?, ?) > > with parameters > $object->id, $object->first_name, $object->last_name, $object->date_of_birth
