| 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: | Whole Thread | Raw Message | 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 |