On Sat, Dec 12, 2009 at 5:09 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > Could we change the API of PQgetXLogData to be more like PQgetCopyData? > I'm thinking of removing the timeout argument, and instead looping with > select/poll and PQconsumeInput in the caller. That probably means > introducing a new state analogous to PGASYNC_COPY_IN. I haven't thought > this fully through yet, but it seems like it would be good to have a > consistent API.
On a related issue, so far I haven't considered about the way to output the notice message at all :( In the current SR, it's always written to stderr by the defaultNoticeProcessor by using fprintf, whether the log_destination is specified or not. This is bizarre, and would need to be fixed. I'm going to set the new function calling ereport as the current notice processor by using PQsetNoticeProcessor. But the problem is that only the completed message like "NOTICE: xxx" is passed to such notice processor, i.e., the error level itself is not passed. So I wonder which error level should be used to output the notice message. There are some approaches to address this; 1. Always use a specific level without regard to the actual one 2. Reverse-engineer the level from the complete message 3. Change some libpq functions so as to pass the error level to the notice processor But nothing really stands out. Do you have another good idea? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
