Bypassing SQL lexer and parser

Le 6 juil. 2015 7:16 PM, "Данила Поярков" <dev@dannote.net> a écrit :

Hello!

What is the best starting point to PostgreSQL internal APIs for operating

directly with the storage (performing basic INSERTs, UPDATEs, SELECTs and
simple JOINs by hand)? I'm looking for something similar to MySQL Cluster
NDB API or InnoDB internal API (the late HailDB and Embedded InnoDB).

Does the PostgreSQL support any other type of plugins/extensions other

than FDW and custom data types? I mean, is it possible to start another
daemon within Postgres without slightly modifying the main codebase?

That sounds a lot like a background worker.

In case you are wondering why could anyone need something like that: I'm

looking for a way to implement a small subset of HTSQL (see [
http://htsql.org/], of course not with the whole HTTP protocol) natively in
one of popular RDBMS without extra URL-to-SQL conversion. Yes, I know that
a lot of hard work was done for making query plans, optimizing etc. but I'm
still really wish to do this for some very specific needs. I'm not going to
completely replace the SQL and thus will be happy to do those manipulations
on a SQL 2008-compliant DBMS.

Good luck with that :-)

--
Guillaume

On 7/6/15 12:14 PM, Данила Поярков wrote:

Hello!

What is the best starting point to PostgreSQL internal APIs for operating directly with the storage (performing basic INSERTs, UPDATEs, SELECTs and simple JOINs by hand)? I'm looking for something similar to MySQL Cluster NDB API or InnoDB internal API (the late HailDB and Embedded InnoDB).

There is support for plugging into the parser and executor, so that
might be a possibility, but...

Does the PostgreSQL support any other type of plugins/extensions other than FDW and custom data types? I mean, is it possible to start another daemon within Postgres without slightly modifying the main codebase?

In case you are wondering why could anyone need something like that: I'm looking for a way to implement a small subset of HTSQL (see [http://htsql.org/], of course not with the whole HTTP protocol) natively in one of popular RDBMS without extra URL-to-SQL conversion. Yes, I know that a lot of hard work was done for making query plans, optimizing etc. but I'm still really wish to do this for some very specific needs. I'm not going to completely replace the SQL and thus will be happy to do those manipulations on a SQL 2008-compliant DBMS.

AFAIK HTSQL is very happy producing SQL; why not just let it hand SQL to
Postgres (which it already does...)

Have you by chance talked to Clark or Kirill about this?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

<div>06.07.2015, 20:28, "Guillaume Lelarge" &lt;guillaume@lelarge.info&gt;:</div><div>&gt; That sounds a lot like a background worker.</div><div>Thank a lot! That's exactly what I was looking for.</div><div> </div><div>07.07.2015, 03:29, "Jim Nasby" &lt;Jim.Nasby@BlueTreble.com&gt;:<br />&gt; There is support for plugging into the parser and executor, so that<br />&gt; might be a possibility, but...</div><div>For now, it's the key question as I didn't find anything like that in PostreSQL docs. There are some good samples of implementing custom background workers but all them use prepared stetements via SPI.</div><div> </div><div>&gt; AFAIK HTSQL is very happy producing SQL; why not just let it hand SQL to <br />&gt; Postgres (which it already does...)</div><div>Yes, they both work like a charm but HTSQL is implemented in Python which adds some extra overhead.<br /><br />&gt; Have you by chance talked to Clark or Kirill about this?<br />Not yet. I'm not currently going to follow all the HTSQL specs (at least at the starting point), just will use them as reference.</div>