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.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
