"Paragon Corporation" writes:
>> So I am guessing you guys are filtering the list so that it works for
>> all FDWs even if the FDW author doesn't directly handle LIMIT / EXCEPT
clause?
> Yes. The FDW author is not expected to implement those clauses; where d
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, December 31, 2015 3:36 PM
To: Paragon Corporation
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] IMPORT FOREIGN SCHEMA return create foreign table
commands are those further filtered in LIMIT and
I've implemented IMPORT FOREIGN SCHEMA support for an fdw called ogr_fdw
against the PostgreSQL 9.5RC1 code base.
Code is here: https://github.com/robe2/pgsql-ogr-fdw
It works great except in the Case of LIMIT TO clause (and possible EXCEPT
though I have to retest EXCEPT to see if there is a c
Just checking to see if you guys have settled on a date for 9.5.0 release.
The PostGIS Dev team would like to release PostGIS 2.2 about or a week or
more before, but not too far ahead of 9.5.0 release.
Thanks,
Regina Obe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Alvaro and Tom,
A big thank you. That seems to have done the trick. My compiler warnings
went away and no more syntax errors in the regress tests. I still have some
regress failures I got to hunt down, but those could be caused by places in
the code I did not replace PRId64 calls or something e
I've been currently suffering an issue in mingw64 with changes made in
PostGIS topology code base. Sadly it only happens to me (compiling in
mingw64)
Issue is when code like this was introduced
appendStringInfo(str, "%s%" PRId64, sep, edge->start_node);
Which uses a PostgreSQL function appe
-- REVISED NOTE --
> Hm. s_lock.h does define TAS() in terms of InterlockedCompareExchange()
if WIN32_ONLY_COMPILER is defined ... but that code hasn't changed in quite
a long time. It
> seems like the combination of an extension built with WIN32_ONLY_COMPILER
and a core built without that flag
> Hm. s_lock.h does define TAS() in terms of InterlockedCompareExchange()
if WIN32_ONLY_COMPILER is defined ... but that code hasn't changed in quite
a long time. It
> seems like the combination of an extension built with WIN32_ONLY_COMPILER
and a core built without that flag should never have
Not sure if people know this, but PostGIS windows builds are built with
mingw64-w32 and mingw64-w64 chains and usually used with EDB VC++ built
PostgreSQL.
This is mostly because there is too much unix stuff ingrained in PostGIS
toolchain making it difficult to compile in VC++.
Anyrate this has w
