Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
От | Adrian Klaver |
---|---|
Тема | Re: Does a call to a language handler provide a context/session, and somewhere to keep session data? |
Дата | |
Msg-id | 56DF6681.3070608@aklaver.com обсуждение исходный текст |
Ответ на | Re: Does a call to a language handler provide a context/session, and somewhere to keep session data? (<david@andl.org>) |
Ответы |
Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
|
Список | 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 по дате отправления: