Hi Maxim, Maxim Sobolev wrote: > 1. There were few places where int8 conversion has been missed, which > resulted in the inability to load flags field from my old location > table. Fixed by myself.
OK. > 2. DB URI parsing code lost one of its features which we use. I've > restored it. OK, I didn't know it was possible to specify the socket this way, thanks. > 3. The previous version was loading INT fields into string AVPs just > fine. The new version refuses doing so. The fix seems to be relatively > simple, however it requires allocating dynamic buffers on heap in the > postgresql driver. I have tried to put something in quickly, but I don't > know enough about memory management in the driver. Perhaps you can fix > it instead. You mean converting integers into strings on the fly? It is true that this conversion has not been implemented but it is easy to fix, I'll do it. > 4. There is no conversion path from PostgreSQL's timestamptz to the > DB_DATETIME. Correct, the description of timestamptz fields isn't very clear in the documentation and there seems to be some confusion about it, see: http://www.postgresql.org/docs/8.3/interactive/datatype-datetime.html Among other things the description says that PostgreSQL internally stores all timestamps in UTC (which is understandable) and when outputting timestamptz fields it converts into the current timezone and the time is displayed in the local timezone, which is less understandable. But this is exactly how timestamp fields behave so I did not understand what timestamtz fields are for. Anyways, if you can live with the fact that SER will stores date time fields in UTC and convert them back to the local timezone of the SER server, even when timestamptz fields are used, then I can add support for timestamptz fields quickly, they will behave just like timestamp fields. Please let me know. > 5. Updating existing data seems to be broken. The driver is apparently > trying to do INSERT instead of UPDATE, which fails due to violation of > unique constraint (see the log at the end of the message). Yes, that's one of the things I mentioned in my previous email, missing support for an equivalent of MySQL REPLACE statement. This is something I have been looking into it already. thanks for the input! Jan. _______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
