Fix python_includespec on Windows at configure time
By converting to using forward slashes at configure time we avoid
having to repeat the logic anywhere that this is needed, such as
in transforms modules for plpython.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/
Enable transforms modules to build and run with Mingw builds.
These modules were all missing essential Windows scaffolding, including
resources files and descriptions, and links to the relevant library
import files. This latter item means that the modules can't be built
with pgxs on Windows, as we
fix escaping of brackets for m4 broken in
b6b2149e48aa61981ae0199c963d5145a37c258c
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/f707b53449f3ab6998c615b746ad01f5775723a3
Modified Files
--
config/python.m4 |2 +-
configure|2 +-
2 files ch
Fix overlooked relcache invalidation in ALTER TABLE ... ALTER CONSTRAINT.
When altering the deferredness state of a foreign key constraint, we
correctly updated the catalogs and then invalidated the relcache state for
the target relation ... but that's not the only relation with relevant
triggers.
Fix overlooked relcache invalidation in ALTER TABLE ... ALTER CONSTRAINT.
When altering the deferredness state of a foreign key constraint, we
correctly updated the catalogs and then invalidated the relcache state for
the target relation ... but that's not the only relation with relevant
triggers.
Peter Eisentraut writes:
> ... I'm confused why prairiedog is complaining
> about that. According to Internet lore, this flag seems to be available
> from OS X either 10.3 or 10.1. prairiedog is listed as 10.4, but errors
> with
> MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1
>
I wrote:
> In short then, my best guess is that the 10.4-era build tools defaulted
> to building 10.1-compatible product files unless you explicitly override
> that by setting MACOSX_DEPLOYMENT_TARGET, which I haven't.
And indeed, explicitly setting MACOSX_DEPLOYMENT_TARGET = 10.4 gets
past the bu
I wrote:
> And indeed, explicitly setting MACOSX_DEPLOYMENT_TARGET = 10.4 gets
> past the build failure. In the interests of getting the buildfarm
> back to green, I've added that to the build environment spec for
> prairiedog (we should have confirmation that it works in an hour or so).
Well, it
Peter Eisentraut writes:
> Move interpreter shared library detection to configure
BTW, the installation documentation concerning Python (installation.sgml
lines 219ff) is badly in need of updates following this commit.
regards, tom lane
--
Sent via pgsql-committers mai
On 05/03/2015 06:27 PM, Tom Lane wrote:
I wrote:
And indeed, explicitly setting MACOSX_DEPLOYMENT_TARGET = 10.4 gets
past the build failure. In the interests of getting the buildfarm
back to green, I've added that to the build environment spec for
prairiedog (we should have confirmation that i
Andrew Dunstan writes:
> On 05/03/2015 06:27 PM, Tom Lane wrote:
>> Well, it sort of works. Looks like the hstore_plpython test is expecting
>> some library function that Python 2.3 doesn't have.
> I don't know if we have a standard for supported Python versions, but
> Python 2.3.0 was released
On 05/03/2015 06:54 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 05/03/2015 06:27 PM, Tom Lane wrote:
Well, it sort of works. Looks like the hstore_plpython test is expecting
some library function that Python 2.3 doesn't have.
I don't know if we have a standard for supported Python version
Second try at fixing warnings caused by commit 9b43d73b3f9bef27.
Commit ef3f9e642d2b2bba suppressed one cause of warnings here, but
recent clang on OS X is still unhappy because we're passing a "long"
to abs(). The fact that tm_gmtoff is declared as long is no doubt a
hangover from days when int
13 matches
Mail list logo
