Search Postgresql Archives

Re: Postgres Pain Points 2 ruby / node language drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Sun, Aug 14, 2016 at 3:42 PM, Karsten Hilbert <Karsten.Hilbert@xxxxxxx> wrote:
Hello Chris,

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

Which is what running where ?

> that says

How ?

One example is of such a service locator is
 http://search.cpan.org/dist/PGObject-Simple/lib/PGObject/Simple.pm

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

--
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@xxxxxxxxxxxxxx)
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.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux