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
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 |