Daniel Farina writes:
> Some of this code was linked with the server, and so reading the node
> using Postgres' parser was easy. Otherwise, a small parser needed be
> written for external projects. Perhaps a slightly more ideal state of
> affairs would be:
>
> * These hooks to acquire the syntacti
On Wed, May 26, 2010 at 6:02 PM, Tatsuo Ishii wrote:
> I'm thinking about exporting the raw parser and related modules as a C
> library. Though this will not be an immediate benefit of PostgreSQL
> itself, it will be a huge benefit for any PostgreSQL
> applications/middle ware those need to parse
On 5/26/2010 10:16 PM, Tatsuo Ishii wrote:
As was already discussed, I don't believe that premise. None of the
applications you cite would be able to make use of the raw parser
output, because it doesn't contain the semantic information they need.
If what you actually meant was the analyzed pars
> My "stand-alone" means libSQL can be used from many modules
> without duplicated codes. For example, copy routines for raw
> parse trees should be in the DLL rather than in postgres.exe.
>
> Then, we need to consider other products than pgpool. Who will
> use the dll? If pgpool is the only user,
Tatsuo Ishii wrote:
> > 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
> 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
> As was already discussed, I don't believe that premise. None of the
> applications you cite would be able to make use of the raw parser
> output, because it doesn't contain the semantic information they need.
> If what you actually meant was the analyzed parse tree, that *might*
> serve the need
Tatsuo Ishii wrote:
> I'm thinking about exporting the raw parser and related modules as a C
> library. Though this will not be an immediate benefit of PostgreSQL
> itself, it will be a huge benefit for any PostgreSQL
> applications/middle ware those need to parse SQL statements.
I read your pr
Tatsuo Ishii writes:
> I'm thinking about exporting the raw parser and related modules as a C
> library. Though this will not be an immediate benefit of PostgreSQL
> itself, it will be a huge benefit for any PostgreSQL
> applications/middle ware those need to parse SQL statements.
As was already
> I think those works are essentially a refactoring of existing raw
> parser, and will not add performance degration nor maintenance cost.
>
> Comments?
You should call it "libSQL"; who knows, other DB projects might want it.
They seem to borrow our parser enough as it is.
--
I'm thinking about exporting the raw parser and related modules as a C
library. Though this will not be an immediate benefit of PostgreSQL
itself, it will be a huge benefit for any PostgreSQL
applications/middle ware those need to parse SQL statements.
For example, pgpool-II parses queries to know
11 matches
Mail list logo
