Skip site navigation (1) Skip section navigation (2)

Re: Win32 open items

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 (view raw or flat)
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: psql.patch
Description: application/octet-stream (5.6 KB)
Attachment: pq.patch
Description: application/octet-stream (11.5 KB)

Responses

pgsql-patches by date

Next:From: Thomas HallgrenDate: 2004-10-30 16:03:56
Subject: Problems using pgxs on Win32
Previous:From: a_ogawaDate: 2004-10-30 14:05:19
Subject: Cache last known per-tuple offsets to speed long tuple access

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group