On 7/7/06, Martijn van Oosterhout <kleptog@svana.org> wrote: Something I've been thinking of while reading this thread. One big
disadvantage of doing it in the backend is that your methods of
returning data are limited. Your resultset can only return one "type".
For example, if you start decoding all the different types of xlog
packets, you're going to get different information for each. To display
that as the output of a function you're going to have to munge them
into a common format. An external program does not suffer this
limitation.
In the future it may be worthwhile making a library that can be used by
both an external program and the postgres backend, but really, that
seems a lot less work than doing the actual decoding itself...
Hope this helps,
Sure, but in the backend idea it could be handled with a functions for the comon data, and other functions to extract especific data from diferent operations.
But I was hoping to get more input about the functionality expected in the standalone tool, what could improve the existing xlogdump?
--
Diogo Biazus -
diogob@gmail.comMóvel Consultoria
http://www.movelinfo.com.br http://www.postgresql.org.br
