public inbox for [email protected]help / color / mirror / Atom feed
Re: Detecting test failures reported as warnings 4+ messages / 2 participants [nested] [flat]
* Re: Detecting test failures reported as warnings @ 2020-06-17 19:31 Chapman Flack <[email protected]> 0 siblings, 2 replies; 4+ messages in thread From: Chapman Flack @ 2020-06-17 19:31 UTC (permalink / raw) To: Kartik Ohri <[email protected]>; +Cc: [email protected] On 06/17/20 13:15, Kartik Ohri wrote: > Out of the box, Powershell only supports MySQL server. ODBC drivers will be > required to be built from source for use with Powershell which I think will > not be worth the complexity. Agreed. > JDBC driver for Java or using python may be a > viable option. I haven't had much success with the python version though. I was looking at the various Python driver choices myself the other night and it wasn't as promising as I thought. pg8000 was the pure-Python one that I remembered, but can't access warnings (as far as I can tell). py-postgresql looks quite promising and has message hooks, but even it has native components, as do several others. I stopped before completing an exhaustive survey. There's a lot to like about a Java and JDBC approach. It shouldn't be hard to get off the ground, JDBC has a nice standard API for finding out about warnings (and reading through the pgJDBC code, I believe it is implemented, though I haven't done a test yet). Later on, as the prerequisites for migrating to TAP get accomplished, that code could just be evolved to match. > In any case, a very simple query suppressed INFO outputs SET > client_min_messages TO WARNING. What should be the behaviour if warnings > are found ? Should be marked as failed or passing. My convention in the existing tests has been to use INFO to report success, and WARNING to report failure. The idea would be to let the test progress as far as it can, even complete if possible, but give an overall not-passing result if there were warnings. Regards, -Chap ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Detecting test failures reported as warnings @ 2020-06-17 19:42 Kartik Ohri <[email protected]> parent: Chapman Flack <[email protected]> 1 sibling, 1 reply; 4+ messages in thread From: Kartik Ohri @ 2020-06-17 19:42 UTC (permalink / raw) To: Chapman Flack <[email protected]>; +Cc: [email protected] > > There's a lot to like about a Java and JDBC approach. It shouldn't be hard > to get off the ground, JDBC has a nice standard API for finding out about > warnings (and reading through the pgJDBC code, I believe it is implemented, > though I haven't done a test yet). > > Later on, as the prerequisites for migrating to TAP get accomplished, > that code could just be evolved to match. > As of now, setting client log level seems to work very well. Should I try to work out this approach or go ahead? ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Detecting test failures reported as warnings @ 2020-06-17 19:53 Chapman Flack <[email protected]> parent: Kartik Ohri <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Chapman Flack @ 2020-06-17 19:53 UTC (permalink / raw) To: Kartik Ohri <[email protected]>; +Cc: [email protected] On 06/17/20 15:42, Kartik Ohri wrote: >> There's a lot to like about a Java and JDBC approach. It shouldn't be hard >> to get off the ground, JDBC has a nice standard API for finding out about >> warnings (and reading through the pgJDBC code, I believe it is implemented, >> though I haven't done a test yet). >> >> Later on, as the prerequisites for migrating to TAP get accomplished, >> that code could just be evolved to match. >> > As of now, setting client log level seems to work very well. Should I try > to work out this approach or go ahead? That sounds adequate for now. Especially if log_min_messages is still at INFO (or could even go finer than that), and you can limit just the client messages to warning, use that to detect success/failure, but put the backend log into the build log. Regards, -Chap ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Detecting test failures reported as warnings @ 2020-07-08 21:37 Chapman Flack <[email protected]> parent: Chapman Flack <[email protected]> 1 sibling, 0 replies; 4+ messages in thread From: Chapman Flack @ 2020-07-08 21:37 UTC (permalink / raw) To: [email protected] On 06/17/20 15:31, Chapman Flack wrote: > I was looking at the various Python driver choices myself the other night > and it wasn't as promising as I thought. pg8000 was the pure-Python one > that I remembered, but can't access warnings (as far as I can tell). For the record, so no future reader of this thread is misinformed, I was wrong about that. pg8000 does make notices/warnings available, using the 'notices' property of a pg8000 Connection. It is a deque that will hold the most recent not-more-than-100 that were received. popleft() will retrieve them in arrival order. Each item is a dict that presents all of the fields of the PostgreSQL notice, keyed by their single-character codes: https://www.postgresql.org/docs/9.6/protocol-error-fields.html So, not only was I mistaken to say "can't access", it in fact provides better access than many other PG drivers. Errors are a bit botched: those raise exceptions of course, and the exception will have a tuple of values. Those are the values of all the fields received from PostgreSQL, just as in the warning case, but with all the keys thrown away, leaving you to guess which field is which. -Chap ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2020-07-08 21:37 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-06-17 19:31 Re: Detecting test failures reported as warnings Chapman Flack <[email protected]> 2020-06-17 19:42 ` Kartik Ohri <[email protected]> 2020-06-17 19:53 ` Chapman Flack <[email protected]> 2020-07-08 21:37 ` Chapman Flack <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox