Re: Faster NUMERIC implementation

On Thu, Mar 20, 2003 at 11:48:33AM -0500, Tom Lane wrote:
> I'm not willing to do that for any very large number of functions; the
> code clutter and runtime overhead would become significant.

But then maintaining the same stuff twice is also a pretty hefty job,
though not during runtime of course.

Actually I only see the special types routines so far.

> I had some visions, back when we were first doing the v1-call-convention
> stuff, that it might be possible to make a script that automatically
> interprets
> ...
> We'd probably have to tighten the consistency of formatting a little
> to make that workable, but it seems more attractive than manually
> maintaining either two sets of code or a wrapper layer.

Maybe we could find a compromise and just move the helper functions
outside. For instance numeric_in() calls get_var_from_str(). The very same
get_var_from string is implemented in pgtypes and called by
PGTYPESnumeric_ntoa() as I called it for now. Moving this does not mean
we have to write a wrapper except for the elog() function. But I'm
willing to change all functions to return error codes that are mapped to
elog() calls. Doesn't look like a big deal IMO.

And this has next to no runtime performance penalty since it is only
used in case of an error, which stops computation anyway.

> But before you get too excited about that, there's also the
> error-handling issue --- and I'm definitely not interested in changing
> all the subroutines away from elog to funny-return-value conventions.

Since I already did this for numeric, it's no big deal. Okay, granted,
it would need a few more error codes, but frankly I'd guess this takes
less than five minutes.

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.

Michael
--
Michael Meskes
Email: Michael(at)Fam-Meskes(dot)De
ICQ: 179140304
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!