Re: [pgsql-hackers-win32] Win32 open items - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [pgsql-hackers-win32] Win32 open items
Date
Msg-id 19872.1099079215@sss.pgh.pa.us
Whole thread Raw
In response to Re: [pgsql-hackers-win32] Win32 open items  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Magnus Hagander wrote:
>> Probably doable, but it requires API additions, I think.

> I thought about this.  There are a lot of pointers in PGconn, and most
> we don't use so I don't like the idea of adding a new API to copy the
> complex PGconn structure just for Win32 psql cancel.  Looking at the
> PQrequestCancel() code, it only writes to errorMessage and reads from
> everything else, and I don't see any of those changing (except
> errorMessage) once the connection is established, so we could do a
> non-deep copy of the structure and reuse all the existing structure
> pointers.  We would just need to create a new errorMessage structure
> because PQrequestCancel() wants to write to that.

I think Magnus had the right idea.  We should invent a completely
separate opaque struct that contains *only* the fields that
PQrequestCancel actually needs (the hostname, port, and secret key;
anything else?) and make a function to create one of these from a
PQconn.  This struct could then be read-only as far as the thread-safe
variant of PQrequestCancel is concerned.

The error message return convention used by PQrequestCancel leaves a lot
to be desired as well; I'd be inclined to think of something else for
the new variant of PQrequestCancel.  Possibly have the caller supply a
buffer to write into.

We could probably reimplement the existing PQrequestCancel on top of the
cleaner version, or at least find some way to share code.  But
basically, the API it has now is pretty bogus.  (I think I can say that,
since I invented it ;-))

            regards, tom lane

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [pgsql-hackers-win32] Win32 open items
Next
From: Bruce Momjian
Date:
Subject: Re: Using ALTER TABLESPACE in pg_dump