Re: src/interfaces/libpq shipping nmake-related Makefiles

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: src/interfaces/libpq shipping nmake-related Makefiles
Date: 2017-04-07 03:20:11
Message-ID: 29375.1491535211@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> While looking at some SCRAM stuff, I have bumped into bcc32.mak and
> win32.mak in src/interfaces/libpq. To put it short: those files are
> not up to date. The code of SCRAM is in the tree for a bit of time
> now, and should have updated those files to list and clean up objects,
> but nobody has reported failures in using them.

> At the minimum, they should be updated. Or perhaps they could just be
> ripped out? Who uses that on Windows now?

I'm quite sure no developers use them, or have done so for years.
The ostensible point is to support people who are trying to build
just libpq on Windows, for use in applications talking to PG servers
elsewhere. It was reasonable that some users would want to
do that back when we didn't have a credible native port of the server,
but it's been quite some time since that was true.

In short, I think we could rip them out without much push-back.
But maybe I'm missing some remaining use-case.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-04-07 03:32:45 Re: No-op case in ExecEvalConvertRowtype
Previous Message Ashutosh Bapat 2017-04-07 03:19:07 Re: No-op case in ExecEvalConvertRowtype