pq more robust
against applications being sloppy about socket readiness checks (which,
you could argue, is exactly what libpqwalreceiver is being). But it
would be a somewhat ticklish change because of the portability hazards,
so I'm really disinclined to do it this late in beta.
Thomas Munro writes:
> On Sat, Aug 12, 2017 at 3:24 AM, Tom Lane wrote:
>> 1. check-hash-bucket-size-against-work_mem-2.patch from
>> https://www.postgresql.org/message-id/13698.1487283...@sss.pgh.pa.us
> +1
> I'd vote for including this in v10. There doesn't se
; rather than "could
not send startup packet". If the initial report was about a setup in
which SSL was enabled, and in this report's setup it isn't, then that
difference is unsurprising; but otherwise it needs explanation.
regards, tom lane
--
Sent
ionality), and he sees no
need for additional progress reports before that. Date X could be
sometime early in September, perhaps.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
ng, here's a corrected patch --- Jobin, please test.
regards, tom lane
diff --git a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c b/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
index de03362..37b481c 100644
--- a/src/backend/replication/libpqwalr
Robert Haas writes:
> On Tue, Aug 8, 2017 at 10:48 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Aug 8, 2017 at 4:34 PM, Tom Lane wrote:
>>>> In the meantime, I think my vote would be to remove AtEOXact_CatCache.
>>> In all supported branches?
Andreas Seltenreich writes:
> Tom Lane writes:
>> I wonder if Andreas would be interested in trying the randomly-timed-
>> SIGTERM thing with sqlsmith.
> So far, most of the core dumps generated are Jeevan's assertion failing
> with backtraces through SearchCatCache
pect we are looking at here is very specific to sigsetjmp
callers: it usually amounts to the compiler unsafely trying to
use the same temporary location for multiple purposes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
y a compiler bug. That function does
not change needCleanup after the sigsetjmp call, so per POSIX it
should not have to label the variable volatile. This is far from
being the first such bug we've seen though.
regards, tom lane
--
Sent via pgsql-hackers mailing l
ption overall than what happens now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier writes:
> On Wed, Aug 9, 2017 at 3:39 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> Let's do that please. Merging both was my first feeling when
>>> refactoring this test upthread. Should I send a patch?
>> Sure, have at it.
> An
n (select id from foo);
Wouldn't recommend holding your breath for that. But you could do the
same conversion on the client side that the parser would do anyway:
select * from foo where id = any ('{1,3,5}'::integer[]);
regards, tom lane
--
Sent via pgsql-h
ases.
Given the new method of handling ArrayCoerceExpr, everything Just Works.
I'll add this to the next commitfest.
regards, tom lane
diff --git a/src/backend/optimizer/prep/preptlist.c b/src/backend/optimizer/prep/preptlist.c
index afc733f..277ca8b 100644
***
Robert Haas writes:
> On Fri, Aug 11, 2017 at 11:24 AM, Tom Lane wrote:
>> 3. remove-pgbench-option-ordering-constraint.patch from
>> https://www.postgresql.org/message-id/20559.1501703...@sss.pgh.pa.us
>>
>> That one was already informally reviewed by two people, s
onstraint.patch from
https://www.postgresql.org/message-id/20559.1501703...@sss.pgh.pa.us
That one was already informally reviewed by two people, so I don't
think it needs another look.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
n this area would be widely useful.
I don't think anyone doubts it would be useful. The question is can we
get to something useful with an acceptable level of effort and overhead.
So far I've not seen anything promising in that sense.
regards, tom lane
--
Sent
have a draft patch, so what we should be pressing for
is for somebody to test it. Peter's not in a position to do that
(and neither am I), but anyone who can build from source on Windows
could do so.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacker
ll pgindent,
please let me know.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Ashutosh Sharma writes:
> On Thu, Aug 10, 2017 at 8:06 PM, Tom Lane wrote:
>> Yeah ... however, if that's there, then there's something wrong with
>> Ashutosh's explanation, because that means we *are* building with
>> _USE_32BIT_TIME_T in 32-bit b
Robert Haas writes:
> On Thu, Aug 10, 2017 at 10:36 AM, Tom Lane wrote:
>> Yeah ... however, if that's there, then there's something wrong with
>> Ashutosh's explanation, because that means we *are* building with
>> _USE_32BIT_TIME_T in 32-bit builds. It
is that _USE_32BIT_TIME_T also affects how
> PostgreSQL code compiles.
Really? We try to avoid touching "time_t" at all in most of the code.
I bet that we could drop the above-cited code, and compile only plperl
with _USE_32BIT_TIME_T, taken (if present) from the Perl flags, and
it&
quality is based on strict
> binary equality.
Yeah. You can change sort order all you want, but you can't easily
change the system's notion of equality. But when people ask for "case
insensitive" collation, they generally want that too.
regards, tom lane
t;the lower bound %s is equal to the
> upper bound" (obviously without including both in the message.)
That seems like overkill. I'm good with "greater than or equal to".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers
ively scanned for.
I believe this coding will work without any further changes for the
case of arrays over domains, but I've not fully tested that yet.
I intend to apply and back-patch this shortly, unless anyone has a
better idea about how to handle such cases.
re
itative file
is indeed a good idea. But I had the impression that people also wanted
to enforce a rule about "only one use of each wait event name", which'd
require a checker script, no? (I'm not really convinced that we need
such a rule, fwiw.)
regards, t
Thomas Munro writes:
> On Wed, Aug 9, 2017 at 3:44 PM, Tom Lane wrote:
>> Hmm, looking into Makefile.global.in, that step seems to be conditional on
>> MAKELEVEL:
> Ah, right. That coding is recommended in the GNU make manual to
> distinguish from explicit invocation and
Robert Haas writes:
> On Wed, Aug 9, 2017 at 10:14 AM, Tom Lane wrote:
>> Thomas Munro writes:
>>> As for whether hypothetical check scripts would ever be run, I was
>>> thinking we should stick them under some make target that developers
>>> run a
as early in the pipeline as possible?
Adding overhead to every developer's every test cycle doesn't sound
like a win. Possibly a reasonable compromise would be to have some
buildfarm members running this check.
regards, tom lane
--
Sent via pgsql-hackers maili
Michael Paquier writes:
> On Tue, Aug 8, 2017 at 11:33 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> I got the same thought, wondering as well if get_slot_xmins should be
>>> renamed check_slot_xmins with the is() tests moved inside it as well.
>>> Not s
a DESTDIR='$(abs_top_builddir)'/tmp_install install
>>'$(abs_top_builddir)'/tmp_install/log/install.log || exit; done)
endif
endif
I'm not real clear on how make invoking gmake would end up affecting
gmake's initial value of MAKELEVEL, but I bet the pro
precedes lower bound \"%s\"." I think "succeeds" has
more alternate meanings than "precedes", so the wording you have seems
more confusing than it needs to be. (Of course, the situation could be
the opposite in other languages, but translators have the abilit
ne. Too bad it just
missed the train for 9.6.4.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Tue, Aug 8, 2017 at 4:34 PM, Tom Lane wrote:
>> In the meantime, I think my vote would be to remove AtEOXact_CatCache.
> In all supported branches?
Whatever we do about this issue, I don't feel a need to do it further
back than HEAD. It's a no
Michael Paquier writes:
> On Tue, Jun 27, 2017 at 3:44 AM, Tom Lane wrote:
>> Looks good as far as it goes, but I wonder whether any of the other
>> get_slot_xmins calls need polling too. Don't feel a need to add such
>> calls until someone exhibits a failure
Robert Haas writes:
> On Tue, Aug 8, 2017 at 12:26 PM, Tom Lane wrote:
>> Yeah, I thought about weakening the assertions too, but I couldn't
>> see a fix of that kind that didn't seem mighty ad-hoc.
> More concretely, the present example seems no different th
Robert Haas writes:
> On Tue, Aug 8, 2017 at 11:36 AM, Tom Lane wrote:
>> We could respond to this by using PG_ENSURE_ERROR_CLEANUP there instead
>> of plain PG_TRY. But I have an itchy feeling that there may be a lot
>> of places with similar issues. Should we be rev
to make it less unlike elog(ERROR)?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrey Borodin writes:
> 7 авг. 2017 г., в 18:37, Tom Lane написал(а):
>> Yeah. Keep in mind that if the extension does anything at all that could
>> possibly throw an error, and if that error condition persists across
>> multiple tries, you will have broken the databas
itdb did import,
and then in the next release that collation doesn't get imported because
ICU changed their minds on what to advertise, the update situation is not
pretty at all. Certainly it won't get handled transparently. This line
of thinking leads me to believe that we ought t
Andres Freund writes:
> On 2017-08-07 17:30:13 -0400, Tom Lane wrote:
>> Meh. The lack of field complaints about this doesn't indicate to me that
>> we have a huge problem, and in any case, just increasing NUM_RESERVED_FDS
>> would do nothing for the system-
Andres Freund writes:
> On 2017-08-07 17:05:06 -0400, Tom Lane wrote:
>> Probably the best we can hope for there is to have fd.c provide a function
>> "close an FD please", which postgres_fdw could call if libpq fails because
>> of ENFILE/EMFILE, and then retry.
&
Andres Freund writes:
> On 2017-08-07 16:52:42 -0400, Tom Lane wrote:
>> No, I don't think so. If you're depending on the NUM_RESERVED_FDS
>> headroom for anything meaningful, *you're doing it wrong*. You should be
>> getting an FD via fd.c, so that ther
y of ensuring we don't leak epoll FDs at
transaction abort.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan writes:
> On 08/07/2017 04:07 PM, Tom Lane wrote:
>> Sorry, I was imprecise. What I'm suggesting is that you drop the
>> runtime PATH-foolery and instead put this in configure's environment:
>>
>> PROVE=$perlpathdir/prove
>>
>> Ot
Andrew Dunstan writes:
> On 08/07/2017 03:36 PM, Tom Lane wrote:
>> My goodness, that's ugly. Is it really better than injecting
>> "PROVE=prove"? (I'd suggest saying that to configure, not make,
>> so that the configure log bears some resemblance to w
Andrew Dunstan writes:
> On 08/07/2017 03:21 PM, Tom Lane wrote:
>> I'm confused. AFAIK, that commit did not change which "prove" would
>> be used --- at least not unless you change PATH between configure and
>> make. It only changed how specifi
Andrew Dunstan writes:
> On 07/31/2017 01:02 PM, Tom Lane wrote:
>> Record full paths of programs sought by "configure".
> The problem with this commit, as jacana is demonstrating, is that on
> Msys it finds the wrong prove. configure needs to run against the perl
&
TsStatus as part of an extension API. The algorithm used by
BufferSync to schedule buffer writes has changed multiple times
before and doubtless will again; if we're going to have a hook
here it should depend as little as possible on those details.
regards, tom lane
to keep
to the same schedule. Barring objections or bad bugs showing up
soon, I'll make the branch early next week.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
t you're thinking of could be made to work. But a
couple of people have attacked that problem and been unable to finish
it :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
do not think anyone did the legwork
to determine the exact consequences of that bug, or the probability of
someone hitting it in the field. But I think the latter must be really
low, because we haven't heard any field reports that seem to match up.
regards, tom
se is close by and time flies.
> /me reads patches.
> [ assorted objections ]
Given Robert's objections, there's no way we should force these into
Monday's releases. Safer to spend whatever time is needed to get it
right.
regards, tom lane
--
m now.)
Please review.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Shay Rojansky writes:
> Great. Do you think it's possible to backport to the other maintained
> branches as well, seeing as how this is quite trivial and low-impact?
Already done, will be in next week's minor releases. (You timed this
bug report well.)
r
, as per the comments; and if we did, there shouldn't
be any child tables anyway; but if somehow there were, surely the same
consistency argument would imply that we *must* recurse and fix those
child tables. So I just made it "true".
regards, tom lane
--
versions that old; but this patch is not
something to move the compatibility goalposts for when it only takes
an #ifdef to avoid breaking older versions.
(I need to check how far back SSL_SESS_CACHE_OFF goes ... we might
need an #ifdef for that too.)
regards, tom
ror cursor to point to that side
might be a bit painful, but it's probably doable.
Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e case where the recursive result has typmod -1 while
the non-recursive output column has some more-specific typmod, so long
as they match on type OID. That would correspond to what we do in
regular non-recursive UNION situations.
regards, tom lane
--
Sent via pgsql-hac
Andrew Dunstan writes:
> On 07/31/2017 06:54 PM, Tom Lane wrote:
>> but could we do something like
>> my $pflags = "PROVE_FLAGS='" . ($ENV{PROVE_FLAGS} || "--timer") . "'";
>> to allow overriding this choice from the buildfarm config?
Michael Banck writes:
> Am Donnerstag, den 27.07.2017, 15:52 -0400 schrieb Tom Lane:
>> So I'm thinking we should consider the multi-pass patch I posted as
>> a short-term, backpatchable workaround, which we could hope to
>> replace with dependency logic later.
> +
levant, I'd tend to go for elog()
just because it's less typing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[ Shoulda got this out sooner, but better late than never ]
We'll be doing routine quarterly releases of supported Postgres
back branches next week (tarballs wrapped Monday 7th, public
announcement Thursday 10th). We'll release v10 beta3 at the
same time.
re
Robert Haas writes:
> So maybe --load-via-partition-root if nobody likes my previous
> suggestion of --partition-data-via-root ?
WFM.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
here --- if you're veering
far enough away from the standard scenario that that doesn't do it for
you, you might as well just write an all-custom setup script in psql.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
T ... FROM generate_series(...);"
Yeah. I was also thinking that complicated data-generation requirements
could be handled with plpgsql DO blocks, avoiding the need for hard-wired
code inside pgbench.
regards, tom lane
--
Sent via pgsql-hackers mailing li
comment at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8b9d323cb9810109e3e5aab1ead427cbbb7aa77e
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
#x27;s not a vote for the patch as submitted; I haven't reviewed it.
But we need to fix this.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;data" to be a group noun --- "data reside" would read a bit funny IMO.
But certainly this is an utter translatability fail. Maybe pass a boolean
to indicate one of two first sentences to use? Or actually, might as well
consider the entire message string to be one of two translatable
Alvaro Herrera writes:
> Alvaro Herrera wrote:
>> Fix pg_dump's errno checking for zlib I/O
> So this broke a few buildfarm members. I'll into it tomorrow.
I think you forgot to consider the !HAVE_LIBZ case.
regards, tom lane
--
Sent via pgsq
a higher log rating ... but the general rule ought to be
that totally-expected behavior does not deserve a log entry by default.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
you found, rather than
someplace you didn't.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
It doesn't look that hard: AFAICS the problem is just that
process_sql_command() is making premature decisions about whether to
extract parameters from the SQL commands. Proposed patch attached.
regards, tom lane
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgb
t; syntax error instead of warning.
Mmm, yeah, we'd better fix it then, because people will surely try
to use older branches with current Perl. Pushed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
proach is
ERROR: "someview" cannot have constraints
DETAIL: "someview" is a view, which is not a supported kind of relation
for this purpose.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Wed, Aug 2, 2017 at 1:08 PM, Tom Lane wrote:
>> --restore-via-partition-root ?
> I worry someone will think that pg_dump is now restoring stuff, but it isn't.
Well, the point is that the commands it emits will cause the eventual
restore to go through
rd "partition" is perhaps a
> significant flaw, and pg_dump doesn't really reload anything; it just
> dumps.
> The best thing I can come up with after brief thought is
> --partition-data-via-root, but maybe somebody else has a better idea?
--restore-via-partition-root
nge that will violate our translatability rules.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Wed, Aug 2, 2017 at 11:50 AM, Tom Lane wrote:
>> Well, I'm imagining that "-i" would essentially become a short form
>> of "-b initialize", as already happened for -S and -N, where the script
>> looks something like ...
Robert Haas writes:
> On Wed, Aug 2, 2017 at 10:17 AM, Tom Lane wrote:
>> Or in other words, this looks to me quite a bit like the hackery
>> that resulted in pgbench's -S and -N options, before we figured out
>> that making it scriptable was a better answer.
> But
gbench's -S and -N options, before we figured out
that making it scriptable was a better answer.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ires like this could be addressed by invoking a
customized script instead of complicating pgbench's option set.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
Accordingly, what I think we should do is something more like the
attached. Could you see whether it fixes your problem?
regards, tom lane
diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c
index dc307c1..fc6d0f7 100644
--- a/src/b
valid concern here.
Anyway, we don't need a design for this today.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
OID.
But that's not a job for beta time.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
at all on platforms that lack HAVE_LOCALE_T. There's no good reason
for that IMO; not if we're one line of code away from allowing it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
so it's largely moot. What I was really annoyed by
was that PL/Perl failed to build and/or pass regression tests on allegedly
supported Perl versions, and that's sorted now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Peter Eisentraut writes:
> On 8/1/17 10:53, Tom Lane wrote:
>> I think this is actually a bug, because the collations code clearly
>> means to allow clones of the C/POSIX locales --- see eg lc_collate_is_c,
> You seem to say that we should support a "POSIX" locale e
fails to say much
of anything about its error-case behavior, and definitely does not
say that it sets the GetLastError indicator. Still, there's certainly
no chance that printing errno without doing this will be useful.
I would suggest that we do that for starters, and if we hear that
we're still
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut writes:
> On 7/31/17 16:54, Tom Lane wrote:
>> Maybe "which" isn't the best tool for the job, not sure.
> Yeah, "which" is not portable. This would need a bit more work and
> portability testing.
Fair enough. This late in beta i
ached?
BTW, I haven't done it here, but I wonder whether we should not make
PGAC_PATH_PROGS invoke AC_ARG_VAR on the target variable, so that
configure knows that it should be treated as affecting results caching.
regards, tom lane
diff --git a/config/docbook.m4 b/config
plan to keep the TAP tests enabled on prairiedog for HEAD,
but probably not for the back branches after this run cycle
finishes, because it's just too-darn-slow.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut writes:
> On 7/12/17 11:11, Tom Lane wrote:
>> FWIW, we used to have support for building static libpq, but
>> we got rid of it a long time ago. I couldn't find the exact
>> spot in some desultory trawling of the commit history.
> We still build
ssion with
virgin backend state, but I think that violates the spirit if not the
letter of RFC 5077. In any case, implementing it with those semantics
would tie our hands if anyone ever wanted to provide something closer
to true session restoration.
regards, tom lane
--
-24 22:00:09.345678+00
> (1 row)
FWIW, we already tightened that up in v10:
regression=# select to_timestamp('20170-07-24 21:59:57.12345678', '-mm-dd
hh24:mi:ss.us');
ERROR: date/time field value out of range: "20170-07-24 21:59:57.12345678"
There may well
Peter Eisentraut writes:
> On 7/31/17 15:38, Tom Lane wrote:
>> Really? That seems pretty broken, independently of how many variables
>> are affected. But the ones you'd be most likely to do that with are
>> using AC_PATH_PROG already, I think. Having lesser-used p
like much of a win.
I'd almost be inclined to say that we should override that behavior
of AC_PATH_PROG. It is undocumented AFAICS, and it's not amazingly
well thought out, either.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
Peter Eisentraut writes:
> On 7/30/17 12:50, Tom Lane wrote:
>> The reason it does that seems to be that we use AC_CHECK_PROGS
>> rather than AC_PATH_PROGS for locating "prove". I can see no
>> particular consistency to the decisions made in configure.in
>&
Noah Misch writes:
> On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:
>> Anyway, pending some news about compatibility of the MSVC scripts,
>> I think we ought to adjust our docs to state that 5.8.3 is the
>> minimum supported Perl version.
> Works for
701 - 800 of 48047 matches
Mail list logo
