|From:||"Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Peter Eisentraut <peter_e(at)gmx(dot)net>,Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Patches <pgsql-patches(at)postgresql(dot)org>|
|Views:||Raw Message | Whole Thread | Download mbox|
On Wed, 2003-02-19 at 10:11, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Matthew T. O'Connor writes:
> >> I think it's a question of, is this solution one that we want to keep
> >> for a while, or do we want a different implementation of AVD, perhaps
> >> something built into the backend that could take advantage of the FSM
> >> also.
> > To me it seems that this would be much better if kept inside the server.
> I agree, it seems like a server-side implementation would be the only
> credible way to go for a production-grade version of this feature.
> But I don't see anything wrong with building a client-side prototype,
> which is what pg_avd looks like from here. (Unless the client is
> contorted by not being able to get at things it needs.)
I don't think pg_avd is contorted, but it is limited to the data
published by the stats system, so there is no FSM etc...
I also think it would probably be better in the backend, I just wasn't
sure if the additional complexity was worth it. The primary advantage
of a client side implementation is simplicity.
That said, I originally tried to do this in the backend, but found the
task too daunting for me and gave up. When Shridhar started some work
on a client side version I decided to run with that and see how far I
Question: Should I keep working on pg_avd for contrib inclusion in 7.4,
or should I try again on a backend implementation that might be less
likely to get into 7.4?
|Next Message||Jeroen Habets||2003-02-19 17:18:16||Patch AbstractJdbc1Statement.setBoolean support BIT and INTEGER columns|
|Previous Message||Tom Lane||2003-02-19 15:12:51||Re: postgres error reporting|