Function structure in formatting.c

Поиск
Список
Период
Сортировка
От Brendan Jurd
Тема Function structure in formatting.c
Дата
Msg-id 37ed240d0708080436kc4250d5w405d076f9ea6fef@mail.gmail.com
обсуждение исходный текст
Ответы Re: Function structure in formatting.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: HOT patch, missing things
Следующее
От: Bertram Scharpf
Дата:
Сообщение: Re: Wrote a connect-by feature