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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
