| 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: | Whole Thread | Raw Message | 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 |