Agree, the project must choose one path as the starting point. But the two options can be given in the long run.
I still think that as a starting point the functions inside the database are a good option.
The reasons are:
- using SQL to agregate and transform data in any way from the logs.
- it's easier for the DBA in the other use cases where the cluster is still active.
- give more flexibility for managing the xlogs remotely
- I think it's faster to implement and to have a working and usable tool.
And there is one option to minimize the problem in the failed cluster case: the wrapper program could give the option to initdb a temporary area when no connection is given, creating a backend just to analyze a set of xlogs.
After this summer project I could go on and try to use parts of this code to implement a realy standalone tool.
Other option is to start by the standalone tool and create a wrapper function inside postgresql that would just call this external program and extract data from the xlogs using this program's output (with some option to output all data in a CSV format).
On 6/22/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: "Jonah H. Harris" <jonah.harris@gmail.com> writes:
> I think it should certainly be able to run on it's own, but it
> wouldn't be that hard to extend the functions so that they were usable
> from within the database or vice-versa.
Yes it would. The most obvious point is that memory management and
error handling conventions inside the backend are quite different from
what you'd expect to employ in a standalone program. Also the means
you'd use for consulting the system catalogs (in that option to provide
readable names for OIDs) are entirely different.
I think asking for support of both environments is a good way to ensure
that this summer project doesn't get finished :-(
regards, tom lane
--
Diogo Biazus -
diogob@gmail.comMóvel Consultoria
http://www.movelinfo.com.brhttp://www.postgresql.org.br
