Improved (De)Serialization Support
I have added support in readfuncs.c to write out Query and PlannedStmt objects
using nodeToString() and then read them back in. We needed this so that we
could use PREPARE and write the arguments to StorePreparedStatement() out to
a file. We are going then read them back into Postgres on a different server
and use EXECUTE.
Most of the changes involved adding new functions that can do the reverse of
all the functions in outfuncs.c. I am still working on getting the
deserialization part to work correctly, but I wanted to ask two basic
questions:
1) Is there any reason why this shouldn't work? I did have to add calls to
fix_opfuncids() in a couple places for some of the Exprs. Can anybody think
of something else that I should watch out for?
2) Would anyone be interested in committing my changes back to CVS? I want to
know before I move my changes over to a CVS checkout of Postgres.
Thanks!
--
Andy Pavlo
pavlo@cs.brown.edu
Andy Pavlo <pavlo@cs.brown.edu> writes:
I have added support in readfuncs.c to write out Query and PlannedStmt objects
using nodeToString() and then read them back in. We needed this so that we
could use PREPARE and write the arguments to StorePreparedStatement() out to
a file. We are going then read them back into Postgres on a different server
and use EXECUTE.
Um, surely Query objects can be written/read already?
2) Would anyone be interested in committing my changes back to CVS?
I'm not very excited about adding a load of code that will never be
exercised during normal use. That will inevitably be a hotbed of
bit-rot. Now, if the feature that needs it is also being proposed for
inclusion in core, then maybe we could talk.
regards, tom lane
On Saturday 23 February 2008 00:40, Tom Lane wrote:
Andy Pavlo <pavlo@cs.brown.edu> writes:
I have added support in readfuncs.c to write out Query and PlannedStmt
objects using nodeToString() and then read them back in. We needed this
so that we could use PREPARE and write the arguments to
StorePreparedStatement() out to a file. We are going then read them back
into Postgres on a different server and use EXECUTE.Um, surely Query objects can be written/read already?
I meant specifically UpdateStmt, DeleteStmt, and InsertStmt objects.
SelectStmt curiously was already in place.
I'm not very excited about adding a load of code that will never be
exercised during normal use. That will inevitably be a hotbed of
bit-rot. Now, if the feature that needs it is also being proposed for
inclusion in core, then maybe we could talk.
The research project that we are working will not be merged back into
Postgres. The exercise of updating this part of the code for serialization
that we need was very useful for me to understand the internals of Postgres
better. I did spend about two days updating the out/read functions, and I
figure that my enhancements would probably be useful for somebody else in the
future.
At the very least you might want to consider taking my minimal changes to
outfuncs.c, since using nodeToString() is useful for new developers to
understand the nested structures used by the planner and optimizer.
--
Andy Pavlo
pavlo@cs.brown.edu