Re: SET DATESTYLE to time_t style for client libraries?
От | Jason Earl |
---|---|
Тема | Re: SET DATESTYLE to time_t style for client libraries? |
Дата | |
Msg-id | 87sn9n3wxi.fsf@npa01zz001.simplot.com обсуждение исходный текст |
Ответ на | Re: SET DATESTYLE to time_t style for client libraries? (Adam Haberlach <adam@newsnipple.com>) |
Список | pgsql-hackers |
I would suggest taking a look at the mxDateTime package if you want to manipulate dates in Python. Adam Haberlach <adam@newsnipple.com> writes: <snip> > > I'll look into getting it to ingest dates, but it seems > wasteful to have the server take its internal reprentation, > pretty-format it into a nice human-readable representation to send > to the client, and then have the client parse that into something it > can deal with internally. While it is a fairly minor performance > issue, it seems there are a lot of chances for things to go wrong. That's a good point. On the other hand, I trust the PostgreSQL folks to know more about all of the wacky time edge cases than I do. I know that I am not particular excited about using raw time_t values. > I've already had to hack my python libs a bit to make the > money type work correctly. It takes the incoming text, removes '$' > and ',' and then tries to convert it into a float. In the case of > negative values, it will blow up because there are "()" around the > value. I'll submit a patch if anyone is interested. Why not simply use the numeric type? I thought the money type was deprecated. > ...I assume that the ISO-8601 representation itself won't be > changing, but time is silly and there's a lot of edge cases. It'd > be nice to have a way to reliabily tell the server "Give me > standardized raw values, I'll sort things out on my end." Of > course, this may already be happening within the C libraries and I'm > not seeing them inside python. I'll look around a bit more. mxDateTime is your friend. Jason
В списке pgsql-hackers по дате отправления: