Function structure in formatting.c - Mailing list pgsql-hackers

From Brendan Jurd
Subject Function structure in formatting.c
Date
Msg-id 37ed240d0708080436kc4250d5w405d076f9ea6fef@mail.gmail.com
Whole thread Raw
Responses Re: Function structure in formatting.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi hackers,

I'm currently poking around in backend/utils/adt/formatting.c with a
view to improving  to_date() parsing (see thread at
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00513.php),
and I've noticed that the way the functions are organised is pretty
weird.

The original author appears to have gone to great lengths to make the
various functions work both for conversions *to* string, and *from*
string.  For each formatting "keyword" (DD, MM, etc), there is just
one processing function; dch_global, dch_date or dch_time.  Each of
these takes an argument called "is_to_char".  Since parsing a date out
of a string, and formatting a date into a string, are fundamentally
different objectives the functions end up reading a lot like this:

if (is_to_char)
{   // do something
}
else
{   // do something completely different
}

In fact, almost all of the actual formatting code in the file is
enclosed in one of these if .. else blocks.

To my mind, it would make a lot more sense (and make hacking the file
a lot easier) if the processing functions were split into to_char and
from_char variants.  I'm not sure what, if any, advantage is gleaned
by having these functions combined.

I'd like to hear from someone who has more familiarity with
formatting.c on this.  Is there some good reason for keeping the
functions unified?

Obviously there's a fair bit of work in splitting the functions up,
but I'd be willing to do it if only to spare my own sanity when
working on to_date parsing.


pgsql-hackers by date:

Previous
From: "Pavan Deolasee"
Date:
Subject: Re: HOT patch, missing things
Next
From: Bertram Scharpf
Date:
Subject: Re: Wrote a connect-by feature