On Sun, Aug 14, 2016 at 12:35 PM, Karsten Hilbert <karsten.hilb...@gmx.net> wrote:
> On Fri, Aug 12, 2016 at 01:32:33PM +0200, Chris Travers wrote: > > >>> My preference is stored procedures plus service locators > >> > >> Would you care to elaborate a little on the latter (service locators) ? > >> > > > > 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. > > Maybe I am a bit dense. Can you please give an example ? > 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 that says "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 The second approach is to tie to the first argument type (think 'self' in Python). In this case, we'd have a function defined like this: CREATE FUNCTION save(person) RETURNS person LANGUAGE ... AS $$ ...$$; Then we have a different service locator that maps this to the safe function as: SELECT * FROM save(?::person); with a argument that is basically: serialize_to_record_form($object) Of course that's just the start. To make this really usable you have to add some additional functionality but that should be enough to describe the process. > > Thanks, > Karsten > -- > GPG key ID E4071346 @ eu.pool.sks-keyservers.net > E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
