From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Win32 open items |
Date: | 2004-10-30 15:12:16 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE47605B@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
>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 ;-))
Here is an attempt at this. First patch contains the changes to libpq,
second patch contains changes to psql to use this API. Docs not updated
yet, pending approval of the general idea at least :)
(Tested on win32 and slackware linux)
//Magnus
Attachment | Content-Type | Size |
---|---|---|
pq.patch | application/octet-stream | 11.5 KB |
psql.patch | application/octet-stream | 5.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2004-10-30 16:03:56 | Problems using pgxs on Win32 |
Previous Message | a_ogawa | 2004-10-30 14:05:19 | Cache last known per-tuple offsets to speed long tuple access |