Re: Concurrent psql patch - Mailing list pgsql-patches

From Gregory Stark
Subject Re: Concurrent psql patch
Date
Msg-id 87iraikri8.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Concurrent psql patch  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Concurrent psql patch  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-patches
"Andrew Dunstan" <andrew@dunslane.net> writes:

> Greg,
>
> In general this looks quite reasonable. It's a very large patch for a feature
> of this size, but luckily it's mostly changes due to the new pset structure
> rather than new code.

Really? I expected there would be a few issues raised. For one about the need
to use PG_ASYNC from libpq-int.h.

Perhaps what I should do it split it into two patches, one which just adds
\connect& and \S (switch connection) which will be the larger patch because it
has to break out the connection structure like you mention. And a second which
does the asynchronous response handling which is where there may be some
questions about how to handle things.

> There are some places that it doesn't use PG style (e.g. no newline before
> brace after if) and some comments that need to be fixed (e.g. /* XXX get result
> */ )

Ah, but it's not just the comment, if I put an XXX in it's definitely because
there's something I'm not certain about. In this case now that I look at it
again I think it's usually ok to ignore the result but in a session with
ON_ERROR_STOP set (such as one running a script) we would want to exit I
think.

Another XXX is next to the include of libpq-int.h and a third one is where I
have the pg_sleep loop instead of a select/poll loop. It occurs to me now that
that loop should check cancel_pressed too.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Concurrent psql patch
Next
From: Andrew Dunstan
Date:
Subject: Re: Concurrent psql patch