On Thu, Aug 8, 2019 at 7:31 PM Yonatan Misgan <yona...@dtu.edu.et> wrote: > I am Yonathan Misgan from Ethiopia, want to add some functionalities on > PostgreSQL to support Ethiopian locales. I want your advice where I start to > hack the PostgresSQL source code. I have attached some synopsis about the > existing problems of PostgresSQL related with Ethiopian locale specially > related with calendar, date and time format.
Hi Yonatan, I'm not sure if this requires hacking the PostgreSQL source code. It sounds more like an extension. My first impression is that you might not need new types like "date". Instead you might be able to develop a suite of functions that can convert the existing types to and from the display formats (ie strings) and perhaps also components (year, month, day etc) that you use in your calendar system. For example: SELECT to_char_ethiopian(CURRENT_DATE, 'YYYY-MM-DD'), or whatever kind of format control string would be more appropriate. However, I see from https://en.wikipedia.org/wiki/Time_in_Ethiopia that new days start at 1 o'clock, not midnight, so that makes CURRENT_DATE a bit more confusing -- you might need to write a function current_eth_date() to deal with that small difference. Other than that detail, which is really a detail of CURRENT_DATE and not of the date type, dates are internally represented as a number of days since some arbitrary "epoch" day (I think Gregorian 2000-01-01), not as the components you see when you look at the output of SELECT CURRENT_DATE. That is, the Gregorian calendar concepts exist mostly in the display/input functions, and the operators that can add intervals etc. You could supply a different set of functions, but use the same types, and I suspect that'd be convenient because then you'll be able to use Gregorian and Ethiopian conventions with the same data, whenever you need to. It's much the same for timestamps, but with more complicated details. I see that there are libraries and bits of example code around to do the various kinds of calendar maths required for Ethiopian dates in Perl, Python etc. If I were you I think I'd experiment with a prototype implementation using PL/Perl, PL/Python etc (a way to define new PostgreSQL functions written in those languages), and if that goes well, try writing an extension in C to do it more efficiently. The end goal of that woudn't need to be part of PostgreSQL itself, but just an extension that anyone can download and install to use Ethiopian dates conveniently. -- Thomas Munro https://enterprisedb.com