Re: Using postgres planner as standalone component

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ricky Stevens <ristevenj(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Using postgres planner as standalone component
Date: 2017-07-02 16:22:27
Message-ID: 29222.1499012547@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ricky Stevens <ristevenj(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2017-07-02 16:59:53 Re: Multi column range partition table
Previous Message Tom Lane 2017-07-02 15:54:15 Re: Race-like failure in recovery/t/009_twophase.pl