Re: updated win32 patch

Lists: pgsql-patches
From: Neil Conway <neilc(at)samurai(dot)com>
To: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: updated win32 patch
Date: 2003-01-31 04:02:37
Message-ID: 1043985757.3926.76.camel@tokyo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-patches

Folks,

This is the first baby steps toward merging PeerDirect's Win32 work with
CVS HEAD. I started off with the "low hanging fruit" -- a bunch of the
changes in the patch against 7.2.1 have already been merged, or are no
longer applicable to current sources. I've attached a modified version
of Jan's patch with the following changes:

- remove changes to pl_handler.c, pl_funcs.c, pl_exec.c, transam.c,
varsup.c, xact.c, keywords.c, gram.y, inet_net_ntop.c, inet_net_ptop.c,
adt/misc.c, postinit.c, lock.h, sinval.h, sinvaladt.h, c_keywords.c,
preproc/keywords.c, preproc.y, bootparse.y, bootscan.l, deadlock.c,
date.c: already applied to CVS HEAD

- remove changes to password.c, exc.h: files no longer exist in CVS HEAD
(and the changes made are no longer relevant)

- removed changes to gram.y: all the keyword changes have been made
(e.g. IN -> IN_P, ...), and AFAICS the following function that the patch
adds isn't related to Win32 at all:

+ /* For unknown parameter type during parse */
+ void set_param_type(int t, Oid typid)
+ {
+ if ((t > pfunc_num_args) || (t <= 0))
+ return;
+ param_type_info[t - 1] = typid;
+ }

The updated "win32-port-changes-2.diff.gz" is attached; no changes were
made to "win32-port-newfiles.diff.gz".

Cheers,

Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

Attachment Content-Type Size
win32-port-changes-2.diff.gz application/x-gzip 57.1 KB

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: updated win32 patch
Date: 2003-02-03 20:41:32
Message-ID: 3E3ED3FC.258071A2@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-patches

Neil Conway wrote:
and AFAICS the following function that the patch
> adds isn't related to Win32 at all:
>
> + /* For unknown parameter type during parse */
> + void set_param_type(int t, Oid typid)
> + {
> + if ((t > pfunc_num_args) || (t <= 0))
> + return;
> + param_type_info[t - 1] = typid;
> + }

Good catch ...

That one is part of something that enables SPI preparation of plans with
parameters of unknown datatype. The caller of SPI_prepare then will find
the datatypes choosen by the parser/planner in the array passed in. Need
to make that a separate one ...

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #


From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: updated win32 patch
Date: 2003-05-24 05:03:28
Message-ID: 200305240503.h4O53SS02863@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-patches


Jan, have you committed this change to CVS yet?

---------------------------------------------------------------------------

Jan Wieck wrote:
> Neil Conway wrote:
> and AFAICS the following function that the patch
> > adds isn't related to Win32 at all:
> >
> > + /* For unknown parameter type during parse */
> > + void set_param_type(int t, Oid typid)
> > + {
> > + if ((t > pfunc_num_args) || (t <= 0))
> > + return;
> > + param_type_info[t - 1] = typid;
> > + }
>
> Good catch ...
>
> That one is part of something that enables SPI preparation of plans with
> parameters of unknown datatype. The caller of SPI_prepare then will find
> the datatypes choosen by the parser/planner in the array passed in. Need
> to make that a separate one ...
>
>
> Jan
>
> --
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #================================================== JanWieck(at)Yahoo(dot)com #
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073


From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: updated win32 patch
Date: 2003-05-25 13:34:29
Message-ID: 3ED0C665.3030703@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-patches

Bruce Momjian wrote:
> Jan, have you committed this change to CVS yet?

No and I don't see any reason to do so. It was code we needed at
PeerDirect for something that was never supposed to be contributed. I
allways warned that one will have a hard time to get changes into the
CVS that are only for support of proprietary stuff and of no benefit for
anyone else.

Jan

>
> ---------------------------------------------------------------------------
>
> Jan Wieck wrote:
>
>>Neil Conway wrote:
>> and AFAICS the following function that the patch
>>
>>>adds isn't related to Win32 at all:
>>>
>>>+ /* For unknown parameter type during parse */
>>>+ void set_param_type(int t, Oid typid)
>>>+ {
>>>+ if ((t > pfunc_num_args) || (t <= 0))
>>>+ return;
>>>+ param_type_info[t - 1] = typid;
>>>+ }
>>
>>Good catch ...
>>
>>That one is part of something that enables SPI preparation of plans with
>>parameters of unknown datatype. The caller of SPI_prepare then will find
>>the datatypes choosen by the parser/planner in the array passed in. Need
>>to make that a separate one ...
>>
>>
>>Jan
>>
>>--
>>#======================================================================#
>># It's easier to get forgiveness for being wrong than for being right. #
>># Let's break this rule - forgive me. #
>>#================================================== JanWieck(at)Yahoo(dot)com #
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 3: if posting/reading through Usenet, please send an appropriate
>>subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>>message can get through to the mailing list cleanly
>>
>
>

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: updated win32 patch
Date: 2003-05-25 15:02:01
Message-ID: 5607.1053874921@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-patches

Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> Bruce Momjian wrote:
>> Jan, have you committed this change to CVS yet?

> No and I don't see any reason to do so. It was code we needed at
> PeerDirect for something that was never supposed to be contributed. I
> allways warned that one will have a hard time to get changes into the
> CVS that are only for support of proprietary stuff and of no benefit for
> anyone else.

Also, if I am guessing correctly at the point of that code, it's largely
duplicative of a feature that's already in CVS tip (PARSE message allows
types of parameter symbols to be deduced by parser).

regards, tom lane