Re: pgAgent reports failure upon success

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: pgAgent reports failure upon success
Дата
Msg-id CA+OCxox7eSggtdfWKt6NLL92HVvQhOy1UPtfPk4z+cSuA6Dhkg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgAgent reports failure upon success  ("Martin French" <Martin.French@romaxtech.com>)
Ответы Re: pgAgent reports failure upon success  ("Martin French" <Martin.French@romaxtech.com>)
Список pgadmin-support
On Tue, Jul 10, 2012 at 1:57 PM, Martin French
<Martin.French@romaxtech.com> wrote:
> Hi
>
> Thanks for the feedback. I certainly won't be discouraged by it! :)

:-)

>> - You have member name of [Get|Set]LastResult which set/return a
>> member variable called lastStatus. These should be consistent to avoid
>> confusion.
>
> Will amend accordingly.

Thanks.

>> - Rather than setting lastStatus to 0 or -1, why not set it to
>> PQresultStatus(). That seems like it would be more useful in the
>> future (and potentially in the log files).
>
> I'd set it to only two values, as it made the comparison easier. As I see
> it, ExecStatusType ENUM can be anyone of 0 - 8 inclusive, but some of those
> are error messages, so it'd either have to determine which ones are OK and
> which are not either with a case statement or with an extended "if". Happy
> to code that in along the lines of (or inverse, testing for fails...):
>
> switch (rc)
> {
> case PGRES_COMMAND_OK:
> case PGRES_TUPLES_OK:
> case PGRES_COPY_OUT:
> case PGRES_COPY_IN:
> case PGRES_COPY_BOTH:
>
> stepstatus = wxT("s");
> break;
> default:
>
> stepstatus = steps->GetString(wxT("jstonerror"));
> break
> }
>
> If you think that's a more viable option? Let me know and I'll sort it :)

That's a little more complex for this case, but I think it'll make the
dbconn class more useful for the future. You could of course wrap that
switch statement up in the class as well, and offer another public
member that returns a simple boolean indicating if the last status was
a success or failure.

>> - When creating the diff, please use "git diff", or if working from a
>> source tarball (not recommended for development) - take 2 copies and
>> then diff them, eg "diff -c -r pgagent-src/ pgagent-src.orig/ >
>> mypatch.diff". That'll put the entire patch in one file, which makes
>> it much easier to handle and reapply.
>
> I'm afraid I'm limited to source tarballs at the moment. Attempting to pull
> from git gives me "Connection Refused". So will create a single patch file
> using the method suggested.

Hmm, this works for me:

git clone git://git.postgresql.org/git/pgagent.git

or, if you're on a network that blocks the git protocol, you might want to try:

git clone http://git.postgresql.org/git/pgagent.git

Please let me know if that doesn't work, as I'm one of the admins for
that server as well so obviously want to fix any problems.


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgadmin-support по дате отправления:

Предыдущее
От: "Martin French"
Дата:
Сообщение: Re: pgAgent reports failure upon success
Следующее
От: "Martin French"
Дата:
Сообщение: Re: pgAgent reports failure upon success