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

From
Subject Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
Date
Msg-id 007d01d17994$706a2420$513e6c60$@andl.org
Whole thread Raw
In response to Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?  (Jan de Visser <jan@de-visser.net>)
Responses Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
List pgsql-general
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.

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org






pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_upgrade error regarding hstore operator
Next
From: Adrian Klaver
Date:
Subject: Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?