Re: exporting raw parser

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp
Cc: ishii(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: exporting raw parser
Date: 2010-05-27 02:28:25
Message-ID: 20100527.112825.45885983.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I read your proposal says "postgres.exe" will link to "libSQL.dll",
> and "pgpool.exe" will also link to the DLL, right?

Perhaps.

> I think it is reasonable, but I'm not sure what part of postgres
> should be in the DLL. Obviously we should avoid code duplication
> between the DLL and "postgres.exe".
>
> > - create an exportable version of memory manager
> > - create an exportable exception handling routines(i.e. elog)
>
> Are there any other issues? For example,
> - How to split headers for raw parser nodes?
> - Which module do we define T_xxx enumerations and support functions?
> (outfuncs, readfuncs, copyfuncs, and equalfuncs)
>
> The proposal will be acceptable only when all of the technical issues
> are solved. The libSQL should also be available in stand-alone.
> It should not be a collection of half-baked functions.

What do you mean by "should also be available in stand-alone"? If you
want more abstract API than "libSQL", you could invent such a thing
based on it as much as you like. IMO anything need to parse/operate
the raw parse tree should be in libSQL.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2010-05-27 02:28:43 Re: Synchronization levels in SR
Previous Message Tom Lane 2010-05-27 02:21:13 Re: libpq should not be using SSL_CTX_set_client_cert_cb