Excerpts from Dimitri Fontaine's message of vie oct 15 16:15:23 -0300 2010:
> I updated the pg_execute_from_file branch with documentation for the
> function, and added documentation (catalog, functions, custom classes)
> to the main feature branch too.
Hmm. To be honest I don't like the direction that pg_execute_from_file
has taken. (Now that I look, it's been like this since inception). I
have two problems with it: one is that it is #including half the world
into genfile.c. This already smells trouble in itself. I got worried
when I saw the CommandDest declaration. Really, I think having the guts
of postgres.c into that file is not a good idea from a modularisation
point of view.
The other problem is that it's slurping the whole file and executing it
as a single query. This is really two problems: one is that you
shouldn't be trusting that the file is going to be small enough to be
read that way. The other one is that I don't think it's a good idea to
execute it in a fell swoop; seems to be it would be better to split it
into queries, and rewrite/parse/plan/execute them one by one.
I think a better way to go about this is to have another entry point in
postgres.c that executes a query the way you want; and somehow read the
file in small chunks, find where each query ends, and execute them one
by one. (To be honest, I have no idea how to find out where each query
ends. psql knows how to do it, but I'm not sure how trustworthy it is.)
As far as #include lines go, please keep them in alphabetical order. As
a matter of style we always have "postgres.h" alone, then a blank line,
then system includes, another blank, then the rest of the includes.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
