On Wed, Mar 19, 2003 at 10:51:32PM -0500, Tom Lane wrote:
I've been amusing myself the last several evenings by working on a
reimplementation of the NUMERIC datatype, along the lines of previous
discussion (use base-1 digits instead of base-10 so that the number
of iterations of the inner
Michael Meskes [EMAIL PROTECTED] writes:
But I wonder if we could arrange things so the Numeric stuff wents out
of the backend.
With suitable #define hacking you could perhaps take care of the code's
dependencies on palloc/pfree ... but elog is harder, and I don't see any
realistic way to
On Thu, Mar 20, 2003 at 09:49:30AM -0500, Tom Lane wrote:
With suitable #define hacking you could perhaps take care of the code's
dependencies on palloc/pfree ... but elog is harder, and I don't see any
realistic way to handle the backend's function-call conventions as
opposed to conventions
Michael Meskes [EMAIL PROTECTED] writes:
How about some wrapper frunctions in the backend that just call their
helper functions in the lib?
I'm not willing to do that for any very large number of functions; the
code clutter and runtime overhead would become significant.
I had some visions,
[ very off topic ]
Michael Meskes [EMAIL PROTECTED] writes:
I already have to manually sync code (preproc.y = gram.y) and don't
like the idea of having to do it with a lot more code.
I've been wondering for quite awhile if we couldn't find a way to avoid
manually duplicating the backend
I've been amusing myself the last several evenings by working on a
reimplementation of the NUMERIC datatype, along the lines of previous
discussion (use base-1 digits instead of base-10 so that the number
of iterations of the inner loops decreases by a factor of about 4).
It's not ready to
