Re: Postgres Pain Points 2 ruby / node language drivers

From: Chris Travers <chris(dot)travers(at)gmail(dot)com>
To: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Postgres Pain Points 2 ruby / node language drivers
Date: 2016-08-14 14:02:19
Message-ID: CAKt_ZfuRKGMp=xRFeppibNMXKtdqrrGCDUDq6vL5rbOm_EKoHA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, Aug 14, 2016 at 3:42 PM, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
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(at)postgresql(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Karsten Hilbert 2016-08-14 15:24:11 Re: Postgres Pain Points 2 ruby / node language drivers
Previous Message Karsten Hilbert 2016-08-14 13:42:05 Re: Postgres Pain Points 2 ruby / node language drivers