Re: Does a call to a language handler provide a context/session, and somewhere to keep session data? - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
Date
Msg-id 56DF6681.3070608@aklaver.com
Whole thread Raw
In response to Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?  (<david@andl.org>)
Responses Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?  (<david@andl.org>)
List pgsql-general
On 03/08/2016 03:44 PM, david@andl.org wrote:
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Jan de Visser
>
> OK, still not quite sure what your architecture is. Is it
>
>
> (1)
>
>    +---------------+
>    | Client system |
>    +---------------+
>            |
>            v
>    +---------------+
>    |      andl     |
>    +---------------+
>            |
>            v (SQL)
>    +---------------+
>    |     pgsql     |
>    +---------------+
>
> Or (2)
>
>    +---------------+
>    | Client system |
>    +---------------+
>            |
>            v (SQL)
>    +---------------+    +----------+
>    |  driver/pgsql | -> |   andl   |
>    +---------------+    +----------+
>
>
> In case (1), you're writing a driver: you abstract out the actual datastore
> from your client program using andl. In case (2) you have a procedural
> language handler where your client program still consciously connects to a
> pgsql database, and within that database some/all data processing is
> delegated to andl.
>
> [dmb>] It's a fair question, and not obvious at various levels. The plan at
> this stage is to continue to use as much of the Postgres client
> infrastructure as possible, which means sticking with (2). The client will
> definitely connect with a Postgres database and could use ODBC/JDBC/libpq or
> whatever.
>
> [dmb>] But the logical model is more like (1). Andl compiles into byte code
> which is stored as functions in its catalog (which BTW is just another
> Postgres table). The only useful SQL query is: "SELECT func(args);", which
> executes an Andl function with some arguments and returns a result set. It
> is not intended to ever embed an Andl function call into an SQL query as I
> think is done with other languages.
>
> [dmb>] But it would be equally possible to implement (1) directly, using the
> Thrift interface (or something else that I haven't tripped over yet). I have
> an Sqlite implementation that works like that.
>
> The reason I'm asking is to set terminology. I've browsed some of your
> website, and I'm still not clear which of the two options you're after. It
> could even be both I think. So let's set some parameters.
> [dmb>] The website always lags behind. I only started with Postgres about 2
> weeks ago, and I really am only now getting a clear enough idea to be able
> to write coherently about it.
>
> Depending on where that goes, you should get pgsql-hackers involved.
> [dmb>] Love to. It takes time to learn the "culture of the lists" too.

On that subject. I have followed this thread, but only sort of as the
quoting your email client is doing tends to obscure the flow. I know for
me that is making it hard to follow your ideas.

Is that something that can be changed?

>
> Regards
> David M Bennett FACS
>
> Andl - A New Database Language - andl.org
>
>
>
>
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com


pgsql-general by date:

Previous
From:
Date:
Subject: Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
Next
From:
Date:
Subject: Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?