From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch review for logging hooks (CF 2012-01) |
Date: | 2012-03-04 15:45:15 |
Message-ID: | 4F538E0B.9010600@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/20/2012 10:01 AM, Robert Haas wrote:
> On Fri, Jan 20, 2012 at 2:47 AM, Greg Smith<greg(at)2ndquadrant(dot)com> wrote:
>>> The updated patch looks good, marking as 'Ready for Committer'
>> Patches without documentation are never ready for commit. For this one, I'm
>> not sure if that should be in the form of a reference example in contrib, or
>> just something that documents that the hook exists and what the ground rules
>> are for grabbing it.
> Hooks are frequently not documented, and we only sometimes even bother
> to include an example in contrib. We should probably at least have a
> working example for testing purposes, though, whether or not we end up
> committing it.
>
I'm just looking at this patch, and I agree, it should be testable. I'm
wondering if it wouldn't be a good idea to have a module or set of
modules for demonstrating and testing bits of the API that we expose.
src/test/api or something similar? I'm not sure how we'd automate a test
for this case, though. I guess we could use something like pg_logforward
and have a UDP receiver catch the messages and write them to a file.
Something like that should be possible to rig up in Perl. But all that
seems a lot of work at this stage of the game. So the question is do we
want to commit this patch without it?
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-03-04 15:50:39 | Re: Command Triggers, patch v11 |
Previous Message | Boszormenyi Zoltan | 2012-03-04 15:33:32 | Re: ECPG FETCH readahead |