async notification patch for dblink

Started by Marcus Kempeover 17 years ago3 messageshackers
Jump to latest
#1Marcus Kempe
marcus@kempe.cc

This patch adds the ability to retrieve async notifications using dblink,
via the addition of the function dblink_get_notify.

It is written against cvs head, includes documentation and regression
testing. It compiles, tests and works well.

I would be interested in some feedback on the regression test.
My initial thought was to test the function as thoroughly as possible. So I
perform listen and notify commands within the test to be able to test all
aspects of the code. Even though this works well for me, I get the feeling
that this is not the correct way to do it. I can find no other testing of
the listen/notify functionality in the regression tests, and I imagine this
is for good reason.
If someone would care to explain this, and maybe give a hint about what
amount of testing is appropriate for this fairly trivial patch, it would be
appreciated.

Best regards,

Marcus Kempe

Attachments:

dblink_async_notifications-v1.patchtext/x-patch; name=dblink_async_notifications-v1.patchDownload+191-0
#2Bruce Momjian
bruce@momjian.us
In reply to: Marcus Kempe (#1)
Re: async notification patch for dblink

What is the status on this?

---------------------------------------------------------------------------

Marcus Kempe wrote:

This patch adds the ability to retrieve async notifications using dblink,
via the addition of the function dblink_get_notify.

It is written against cvs head, includes documentation and regression
testing. It compiles, tests and works well.

I would be interested in some feedback on the regression test.
My initial thought was to test the function as thoroughly as possible. So I
perform listen and notify commands within the test to be able to test all
aspects of the code. Even though this works well for me, I get the feeling
that this is not the correct way to do it. I can find no other testing of
the listen/notify functionality in the regression tests, and I imagine this
is for good reason.
If someone would care to explain this, and maybe give a hint about what
amount of testing is appropriate for this fairly trivial patch, it would be
appreciated.

Best regards,

Marcus Kempe

[ Attachment, skipping... ]

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#3Marcus Kempe
marcus.kempe@gmail.com
In reply to: Bruce Momjian (#2)
Re: async notification patch for dblink

Hi,

status of the patch is that it's working fine / as expected.

As is the regression test, my only concern there is if it's testing the
functionality thoroughly enough. But at it's current state I suppose it's in
line with the rest of the regression tests for dblink functionality.

Also, please advice if I'm expected to take any additional actions as part
of submitting this patch.

Best regards,

Marcus Kempe

On Wed, Jan 14, 2009 at 23:12, Bruce Momjian <bruce@momjian.us> wrote:

Show quoted text

What is the status on this?

---------------------------------------------------------------------------

Marcus Kempe wrote:

This patch adds the ability to retrieve async notifications using dblink,
via the addition of the function dblink_get_notify.

It is written against cvs head, includes documentation and regression
testing. It compiles, tests and works well.

I would be interested in some feedback on the regression test.
My initial thought was to test the function as thoroughly as possible. So

I

perform listen and notify commands within the test to be able to test all
aspects of the code. Even though this works well for me, I get the

feeling

that this is not the correct way to do it. I can find no other testing of
the listen/notify functionality in the regression tests, and I imagine

this

is for good reason.
If someone would care to explain this, and maybe give a hint about what
amount of testing is appropriate for this fairly trivial patch, it would

be

appreciated.

Best regards,

Marcus Kempe

[ Attachment, skipping... ]

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +