Thread: [HACKERS] Using postgres planner as standalone component

Ricky Stevens <ristevenj@gmail.com> writes:
> For one of my personal projects I am interested in using the PostgreSQL
> planner as a standalone library. However, I would like to run this as an
> embedded library instead of actually creating anything on disk.

I'm not really clear on what value that would have.  Aside from the
problem you mentioned that lots of information comes from the PG
system catalogs, there are a lot of other issues large and small:

* the code depends extensively on the PG backend programming environment
(palloc and elog, for instance);

* the input data structure is a PG-specific query representation, and
the output structure is a PG-specific plan representation;

* the knowledge that it has is all about the behavior of PG-specific
operators and execution plan types.

By the time you got done dealing with all that, either you'd have imported
pretty much the entire Postgres system into your "standalone library",
or you'd have done so much rewrite work that you might as well have
started from scratch.
        regards, tom lane

On 01/07/17 22:48, Ricky Stevens wrote:
> Hi,
>
> For one of my personal projects I am interested in using the 
> PostgreSQL planner as a standalone library. However, I would like to 
> run this as an embedded library instead of actually creating anything 
> on disk.
>
> I've realized that postgres has several pg_operator, pg_class etc. 
> tables which it uses for query planning purposes. Is there any 
> PostgreSQL component interface whose implementation could be 
> overridden to not actually try to read these tables from disk but 
> instead read it from a custom memory region that is managed by my code.
>
> Thanks!
>
    Maybe you'd like to consider gporca 
https://github.com/greenplum-db/gporca as an alternative. You may also 
want to look at Calcite https://calcite.apache.org/docs/ if you were 
more into the Java world.

    Álvaro

-- 

Álvaro Hernández Tortosa


-----------
<8K>data