[HACKERS] Infer INOUT Parameters from Frontend/Backend Protocol
Hi, I'm currently working on improving Npgsql's NpgsqlCommandBuilder.DeriveParameters method which is intended to automatically populate parameter information for a NpgsqlCommand. As Shay Rojansky suggested to use a Parse/Describe -> ParameterDescription/RowDescription over the backend protocol instead of querying pg_proc (https://github.com/npgsql/npgsql/pull/912#issuecomment-167557036) in order to derive the properties of Parameters (data type, name, direction) I'm currently investigating this approach. The benefit of this would be that we could avoid duplicating quite a bit of backend functionality in order to find the correct overload of a specified function. Also it seems to be the best way to derive parameters from prepared SQL-statements that are not function calls. While having a closer look at the details of the ParameterDescription/RowDescription that the backend returns after a Parse/Describe message I come to the conclusion that there is no valid way to always find out whether a parameter is IN or INOUT from these Messages. Example: Given the following function CREATE OR REPLACE FUNCTION my_func(IN param1 integer, OUT param2 integer, INOUT param3 integer) RETURNS record AS 'BEGIN param3 = param1 + param2 + param3; END;' LANGUAGE 'plpgsql'; After sending a Parse message for 'SELECT* FROM my_func($1,$2)' followed by aDescribe message I'll get back a ParameterDescription message containing the OIDs of the two inwards bound parameters (and a void OID for the OUT parameter) followed by a RowDescription message containing the names and OIDs of the two OUT parameters. Without additional knowledge of the exact function definition (parsing it or hardcoding information about it) I can only figure out that there are three parameters in total with two of them being inwards bound and two of them being outwards bound. I can also tell that the second parameter is a real OUT Parameter (from void OID in the ParameterDescription message). But what I can't tell by any means is whether the first parameter is the INOUT one or the last Parameter is the INOUT one i.e. wheter it's (IN,OUT,INOUT) or (INOUT,OUT,IN) Digging around in the history of PostgreSQLs OUT and INOUT parameter support (http://www.postgresql.org/message-id/flat/421eca30.8040...@samurai.com#421eca30.8040...@samurai.com) and poking around in the respective commits (git log --after="2005-01-19" --before="2005-11-08" --author="Tom Lane" --grep="OUT") helped me to understand why things are like they are (i. e. why OUT Parameters are implemented more like rows than like parameters and why the ParameterDescription message gives so little information about them) but still I'd whish that the ParameterDescription message would contain the whole Information about all the parameters (name, type, direction). Anyways, as I don't expect you to change the Frontend/Backend Protocol due to my whishes I just want to confirm that things really are the way I understand them and that I'm not overlooking something obvious. If I'm right ParameterDescription path is probably a blind end for parameter derivation in Npgsql and I'll probably have to stick with the "query pg_proc"-way. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?
Andres Freund wrote: That seems like a pretty straight forward bug. But it hinges on the client side calling shutdown() on the socket. I don't know enough about .net's internals to judge wether it does so. I've traced things far enough to find "Disposing a Stream object flushes any buffered data, and essentially calls the Flush method for you. Dispose also releases operating system resources such as file handles, network connections, or memory used for any internal buffering. The BufferedStream class provides the capability of wrapping a buffered stream around another stream in order to improve read and write performance." https://msdn.microsoft.com/en-us/library/system.io.stream%28v=vs.110%29.aspx which'd plausibly use shutdown(). In the new days of Microsoft you can confirm that even more... http://referencesource.microsoft.com/#System/net/System/Net/Sockets/Socket.cs,6245 Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Perl coding error in msvc build system?
Am 23.01.2015 um 09:17 schrieb Abhijit Menon-Sen: At 2014-06-03 22:30:50 -0400, pete...@gmx.net wrote: I'm not sure whether the following coding actually detects any errors: Solution.pm: open(P, cl /? 21 |) || die cl command not found; Since nobody with a Windows system has commented, I'm just writing to say that from a Perl perspective, I agree with your analysis and the patch looks perfectly sensible. I can confirm it on my Windows system. Calling build from a console without nmake in the path I always get: Unable to determine Visual Studio version: The nmake version could not be determined. at src/tools/msvc/Mkvcbuild.pm line 63. This means that the following construct in VSObjectFactory.pm doesn't have the desired effect. open(P, nmake /? 21 |) || croak Unable to determine Visual Studio version: The nmake command wasn't found.; On the other hand complicacy is in the eye of the beholder. Perl constructs like the following get quite a few wtf's (http://www.osnews.com/story/19266/WTFs_m) from a simple-minded person like me. $? 8 == 0 or die cl command not found; However as it fixes a confirmed problem and as maintainance of perl code is an issue of its own, please go ahead. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Visual Studio 2013 build
Hackers,
the attached patch enables Microsoft Visual Studio 2013 as additional
build environment.
After some tweaking (VS now has got its own rint and a few macro
definitions that were previously missing) the build runs without errors
or warnings and the product passes the regression tests.
I didn't test any special configurations though.
I'm using full Visual Studio 2013 actually so I can't conform that
everything still works with Visual Studio Express 2013 for Windows
Desktop, but there are no documented limitations that make any problems
foreseeable.
I will add it to the CommitFest 2014-01 so that there is time for
testing and tweaking.
Regards,
Brar
diff --git a/doc/src/sgml/install-windows.sgml
b/doc/src/sgml/install-windows.sgml
index 4c9ce5b..c564166 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -19,12 +19,12 @@
para
There are several different ways of building PostgreSQL on
productnameWindows/productname. The simplest way to build with
- Microsoft tools is to install productnameVisual Studio Express 2012
+ Microsoft tools is to install productnameVisual Studio Express 2013
for Windows Desktop/productname and use the included
compiler. It is also possible to build with the full
- productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some
cases
- that requires the installation of the productnameWindows SDK/productname
- in addition to the compiler.
+ productnameMicrosoft Visual C++ 2005 to 2013/productname.
+ In some cases that requires the installation of the
+ productnameWindows SDK/productname in addition to the compiler.
/para
para
@@ -77,15 +77,15 @@
productnameVisual Studio Express/productname or some versions of the
productnameMicrosoft Windows SDK/productname. If you do not already have
a
productnameVisual Studio/productname environment set up, the easiest
- ways are to use the compilers in the productnameWindows SDK
7.1/productname
- or those from productnameVisual Studio Express 2012 for Windows
- Desktop/productname, which are both free downloads from Microsoft.
+ ways are to use the compilers from productnameVisual Studio Express 2013
+ for Windows Desktop/productname or those in the productnameWindows SDK
+ 7.1/productname, which are both free downloads from Microsoft.
/para
para
PostgreSQL is known to support compilation using the compilers shipped with
productnameVisual Studio 2005/productname to
- productnameVisual Studio 2012/productname (including Express editions),
+ productnameVisual Studio 2013/productname (including Express editions),
as well as standalone Windows SDK releases 6.0 to 7.1.
64-bit PostgreSQL builds are only supported with
productnameMicrosoft Windows SDK/productname version 6.0a to 7.1 or
diff --git a/src/backend/utils/adt/float.c b/src/backend/utils/adt/float.c
index 54690bd..3df877d 100644
--- a/src/backend/utils/adt/float.c
+++ b/src/backend/utils/adt/float.c
@@ -111,6 +111,14 @@ get_float8_infinity(void)
#endif
}
+/*
+* The funny placements of the two #pragmas is necessary because of a
+* log lived bug in the Microsoft compilers.
+* See http://support.microsoft.com/kb/120968/en-us for details
+*/
+#if (_MSC_VER = 1800)
+#pragma warning(disable:4756)
+#endif
float
get_float4_infinity(void)
{
@@ -118,6 +126,9 @@ get_float4_infinity(void)
/* C99 standard way */
return (float) INFINITY;
#else
+#if (_MSC_VER = 1800)
+#pragma warning(default:4756)
+#endif
/*
* On some platforms, HUGE_VAL is an infinity, elsewhere it's just the
diff --git a/src/bin/pg_ctl/pg_ctl.c b/src/bin/pg_ctl/pg_ctl.c
index 8399cdd..2c8a0e9 100644
--- a/src/bin/pg_ctl/pg_ctl.c
+++ b/src/bin/pg_ctl/pg_ctl.c
@@ -133,6 +133,12 @@ static void print_msg(const char *msg);
static void adjust_data_dir(void);
#if defined(WIN32) || defined(__CYGWIN__)
+#if (_MSC_VER = 1800)
+#include versionhelpers.h
+#else
+static bool IsWindowsXPOrGreater(void);
+static bool IsWindows7OrGreater(void);
+#endif
static bool pgwin32_IsInstalled(SC_HANDLE);
static char *pgwin32_CommandLine(bool);
static void pgwin32_doRegister(void);
@@ -1224,6 +1230,29 @@ do_kill(pgpid_t pid)
#if defined(WIN32) || defined(__CYGWIN__)
+#if (_MSC_VER 1800)
+static bool
+IsWindowsXPOrGreater(void)
+{
+ OSVERSIONINFO osv;
+ osv.dwOSVersionInfoSize = sizeof(osv);
+
+/* Windows XP = Version 5.1 */
+ return (!GetVersionEx(osv) || /* could not get version */
+ osv.dwMajorVersion 5 || (osv.dwMajorVersion == 5
osv.dwMinorVersion = 1));
+}
+
+static bool IsWindows7OrGreater(void)
+{
+ OSVERSIONINFO osv;
+ osv.dwOSVersionInfoSize = sizeof(osv);
+
+/* Windows 7 = Version 6.0 */
+ return (!GetVersionEx(osv) || /* could not get version */
+ osv.dwMajorVersion 6 || (osv.dwMajorVersion == 6
osv.dwMinorVersion = 0));
+}
+#endif
+
static bool
Re: [HACKERS] Visual Studio 2012 RC
On 01/23/2013 02:14 PM, Craig Ringer wrote: How have you been testing VS2012 builds? In what environment? When I tested this patch the last time I've been using Windows 8 RTM (Microsoft Windows 8 Enterprise Evaluation - 6.2.9200 Build 9200) and Microsoft Visual Studio Express 2012 für Windows Desktop RTM (Version 11.0.50727.42) Regards, Brar
Re: [HACKERS] Visual Studio 2012 RC
Alvaro Herrera wrote: There having been no updated patch yet, I have closed this as returned with feedback. Thanks Noah! Please make sure to submit an updated patch to the upcoming commitfest, which is due to start in about three weeks. Due to an hyperacute increase of workload in my day job I currently can't promise anything. Sorry! Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
Noah Misch wrote: The only matter still requiring attention is a fix for IsoLocaleName(). Yep - I'll work on this and on some denoisifying of the build log files. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
Noah Misch wrote:
My build log filled 8.8 MiB, a large increase from the 432 KiB of the chough
build log. This isn't strictly a problem, but do you happen to have ideas for
curbing the noise?
Not yet.
I find no functional problems with the patch, but some comment updates and
other trivia need attention. The patch itself was reversed; it applied
cleanly with patch -R. I regenerated it in the usual direction for the
portions I quote below.
src/tools/msvc/MSBuildProject.pm:4:# Package that encapsulates a MSBuild
(Visual C++ 2010) project file
Say something like Visual C++ 2010 or greater.
src/tools/msvc/VSObjectFactory.pm:93:# we use nmake as it has existed for a
long time and still exists in visual studio 2010
Likewise, modify this comnent to be open-ended. If nmake ever disappears,
we'll be updating this code and can see to change the comment.
fixed
*** a/doc/src/sgml/install-windows.sgml
--- b/doc/src/sgml/install-windows.sgml
***
*** 22,28
Microsoft tools is to install a supported version of the
productnameMicrosoft Windows SDK/productname and use the included
compiler. It is also possible to build with the full
! productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some
cases
that requires the installation of the productnameWindows
SDK/productname
in addition to the compiler.
/para
--- 22,28
Microsoft tools is to install a supported version of the
productnameMicrosoft Windows SDK/productname and use the included
compiler. It is also possible to build with the full
! productnameMicrosoft Visual C++ 2005, 2008, 2010 or 2012/productname.
In some cases
that requires the installation of the productnameWindows
SDK/productname
in addition to the compiler.
/para
I think this paragraph should be more like the one in the next patch hunk:
call out Visual Studio 2012 Express for Windows Desktop and Windows SDK 7.1 as
the main recommendations. Perhaps even demote the SDK entirely and just
recommend VS 2012. It'd odd to recommend only a past-version tool if a
current-version tool works just as well.
fixed.
I would write Windows SDK 7.1 here and remove the parenthesized bit.
There's a later mention of support for older versions.
! (= 7.1) or those from productnameVisual Studio Express 2012 for Windows
! Desktop/productname, which are both free downloads from Microsoft.
fixed.
The part ending here looks like this:
varlistentry
termproductnameMicrosoft Windows SDK/productname/term
listitempara
It is recommended that you upgrade to the latest supported version
of the productnameMicrosoft Windows SDK/productname (currently
version 7.1), available for download from
ulink url=http://www.microsoft.com/downloads/;/.
/para
para
You must always include the
applicationWindows Headers and Libraries/application part of the SDK.
If you install the productnameWindows SDK/productname
including the applicationVisual C++ Compilers/application,
you don't need productnameVisual Studio/productname to build.
Note that as of Version 8.0a the Windows SDK no longer ships with a
complete command-line build environment.
/para/listitem
/varlistentry
Since SDK version 7.1 is named as the latest supported version, I understand
from that text that installing SDK version 8.0a along with compilers from
another source (VS 2012 full, VS 2012 Express for Desktop) is considered
unsupported as a PostgreSQL build environment. Is that your intent?
No, not really.
What I want to say is that you'll need the SDK to build postgres.
Using a Visual Studio version that ships with a supported SDK version
(full versions of VS 2005 to 2010 as well as any version of VS 2012)
will work.
On the other hand standalone SDK versions that ship with compilers will
also work.
The major gotcha here is the fact that old sdk versions ship without
compilers and old VS Express versions ship without SDK and you'll need
both to build.
I've tried to change the wording to make this more clear but perhaps
someone else (native speaker) finds a better aproach to make this clear.
*** a/src/tools/msvc/MSBuildProject.pm
--- b/src/tools/msvc/MSBuildProject.pm
***
*** 397,400 sub new
--- 397,440
return $self;
}
+ package VC2012Project;
+
+ #
+ # Package that encapsulates a Visual C++ 2012 project file
+ #
+
+ use strict;
+ use warnings;
+ use base qw(MSBuildProject);
+
+ sub new
+ {
+ my $classname = shift;
+ my $self = $classname-SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self-{vcver} = '11.00';
+
+ return $self;
+ }
+
+ sub WriteConfigurationPropertyGroup
Please add a comment explaining what this override does differently. (I think
it just adds the PlatformToolset element.)
done.
Regards,
Brar
diff -Napcdr -x .git
Re: [HACKERS] Visual Studio 2012 RC
Noah Misch wrote: I decided to try a 32-bit build, but Solution::DeterminePlatform detected it as x64. Its shibboleth is no longer valid; the cl.exe shipping with VS 2012 Express for Desktop has a /favor option for both architectures: 32clhelp:/favor:blend|ATOM select processor to optimize for, one of: 64clhelp:/favor:blend|AMD64|INTEL64|ATOM select processor to optimize for, one of: Overlaying the first attached change fixed detection for this particular compiler, but I have not checked compatibility with older versions. Do you have VS 2008 and/or VS 2010 handy? Older compilers work fine but localized ones will probably cause trouble (for - für in german). I've decided to change the regex to /^\/favor:.+AMD64/ in my current version of the patch as this is not very likely to appear in a 32-bit environment and will not be subject ot localization problems. Having worked around that, the build eventually failed like this: Creating library Debug\postgres\postgres.lib and object Debug\postgres\postgres.exp postgres.exp : error LNK2001: unresolved external symbol _xmm@41f0 [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj] postgres.exp : error LNK2001: unresolved external symbol _xmm@80008000 [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj] postgres.exp : error LNK2001: unresolved external symbol _xmm@8000800080008000 [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj] .\Debug\postgres\postgres.exe : fatal error LNK1120: 3 unresolved externals [c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj] The command exited with code 1120. Done executing task Link -- FAILED. This compiler emits _xmm symbols automatically, where needed. The second attached change lets the build complete and pass tests, but I can't readily explain why it's necessary. In the 64-bit build, the _xmm symbols export normally (albeit, I presume, needlessly). I hoped to find some rationale for the preexisting gendef.pl exclusion of _real, which seems to resemble _xmm in origin and use. Magnus/anyone, can you shed light on our exclusion of _real symbols from .def files? I kind of feel like excluding the _xmm symbols is the right thing to do but - like you - I can't explain why they cause problems in a x86 build. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
Noah Misch wrote: I'm marking this patch Waiting on Author, but the changes needed to get it Ready for Committer are fairly trivial. Thanks, nm Thanks for your review and sorry for my delayed response - I've been on vacation. I'll look into adressing your comments and suggestions within the next few days. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2012 RC
Heikki Linnakangas wrote:
I don't think we can realistically support VS2012 until Microsoft
releases the gratis Visual Studio Express 2012 for Windows Desktop.
As they've released now I've updated my Patch with docs and ask for review.
Regards,
Brar
diff -Napcdr -x .git postgres/doc/src/sgml/install-windows.sgml
postgres_dev/doc/src/sgml/install-windows.sgml
*** postgres/doc/src/sgml/install-windows.sgml Thu Sep 13 23:17:21 2012
--- postgres_dev/doc/src/sgml/install-windows.sgml Thu Sep 13 23:22:03 2012
***
*** 22,28
Microsoft tools is to install a supported version of the
productnameMicrosoft Windows SDK/productname and use the included
compiler. It is also possible to build with the full
! productnameMicrosoft Visual C++ 2005, 2008, 2010 or 2012/productname.
In some cases
that requires the installation of the productnameWindows SDK/productname
in addition to the compiler.
/para
--- 22,28
Microsoft tools is to install a supported version of the
productnameMicrosoft Windows SDK/productname and use the included
compiler. It is also possible to build with the full
! productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some
cases
that requires the installation of the productnameWindows SDK/productname
in addition to the compiler.
/para
***
*** 77,91
productnameVisual Studio Express/productname or some versions of the
productnameMicrosoft Windows SDK/productname. If you do not already
have a
productnameVisual Studio/productname environment set up, the easiest
! ways are to use the compilers in the productnameWindows SDK/productname
! (= 7.1) or those from productnameVisual Studio Express 2012 for Windows
! Desktop/productname, which are both free downloads from Microsoft.
/para
para
PostgreSQL is known to support compilation using the compilers shipped with
productnameVisual Studio 2005/productname to
! productnameVisual Studio 2012/productname (including Express editions),
as well as standalone Windows SDK releases 6.0 to 7.1.
64-bit PostgreSQL builds are only supported with
productnameMicrosoft Windows SDK/productname version 6.0a and above or
--- 77,90
productnameVisual Studio Express/productname or some versions of the
productnameMicrosoft Windows SDK/productname. If you do not already
have a
productnameVisual Studio/productname environment set up, the easiest
! way is to use the compilers in the productnameWindows SDK/productname,
! which is a free download from Microsoft.
/para
para
PostgreSQL is known to support compilation using the compilers shipped with
productnameVisual Studio 2005/productname to
! productnameVisual Studio 2010/productname (including Express editions),
as well as standalone Windows SDK releases 6.0 to 7.1.
64-bit PostgreSQL builds are only supported with
productnameMicrosoft Windows SDK/productname version 6.0a and above or
*** $ENV{PATH}=$ENV{PATH} . ';c:\some\where\
*** 158,165
If you install the productnameWindows SDK/productname
including the applicationVisual C++ Compilers/application,
you don't need productnameVisual Studio/productname to build.
- Note that as of Version 8.0a the Windows SDK no longer ships with a
- complete command-line build environment.
/para/listitem
/varlistentry
--- 157,162
*** $ENV{PATH}=$ENV{PATH} . ';c:\some\where\
*** 201,210
Bison can be downloaded from ulink
url=http://gnuwin32.sourceforge.net;/.
Flex can be downloaded from
ulink url=http://www.postgresql.org/ftp/misc/winflex/;/.
! If you are using productnamemsysGit/productname or
productnameGitHub for
! Windows/productname for accessing the PostgreSQL
productnameGit/productname
! repository you probably already have recent versions of bison and flex
in your
! productnameGit/productname binary directory.
/para
note
--- 198,207
Bison can be downloaded from ulink
url=http://gnuwin32.sourceforge.net;/.
Flex can be downloaded from
ulink url=http://www.postgresql.org/ftp/misc/winflex/;/.
! If you are using productnamemsysGit/productname for accessing the
! PostgreSQL productnameGit/productname repository you probably
already
! have recent versions of bison and flex in your
productnameGit/productname
! binary directory.
/para
note
diff -Napcdr -x .git postgres/src/tools/msvc/MSBuildProject.pm
postgres_dev/src/tools/msvc/MSBuildProject.pm
*** postgres/src/tools/msvc/MSBuildProject.pm Thu Sep 13 23:17:32 2012
--- postgres_dev/src/tools/msvc/MSBuildProject.pm Thu Sep 13 23:22:03 2012
*** sub new
*** 397,440
return $self;
}
- package VC2012Project;
-
- #
- # Package that encapsulates a Visual C++ 2012 project file
- #
-
Re: [HACKERS] Visual Studio 2012 RC
Magnus Hagander wrote: I don't have too much hope for them actually changing it - they seem hell-bent on forcing everybody into metro, and this seems to be yet another way to do that. But we can always hope... Looks like they've learnt their lesson... http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Visual Studio 2012 RC
The attached patch makes postgres build with Visual Studio 2012 RC.
As MS finally decided on the name I don't expect any need for changes
for the final RTM.
I didn't bother to update the docs for now as I still have some hope
that the developer community succeds in pushig M$ to reverse this decision:
http://people.planetpostgresql.org/andrew/index.php?/archives/276-Microsoft-throws-large-developer-communities-under-the-bus.html
Regards,
Brar
diff -Napcdr -x .git postgresql/src/tools/msvc/MSBuildProject.pm
postgresql_dev/src/tools/msvc/MSBuildProject.pm
*** postgresql/src/tools/msvc/MSBuildProject.pm Tue Jan 3 15:56:06 2012
--- postgresql_dev/src/tools/msvc/MSBuildProject.pm Wed Mar 14 23:59:07 2012
*** sub new
*** 385,388
--- 385,428
return $self;
}
+ package VC2012Project;
+
+ #
+ # Package that encapsulates a Visual C++ 2012 project file
+ #
+
+ use strict;
+ use warnings;
+ use base qw(MSBuildProject);
+
+ sub new
+ {
+ my $classname = shift;
+ my $self = $classname-SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self-{vcver} = '11.00';
+
+ return $self;
+ }
+
+ sub WriteConfigurationPropertyGroup
+ {
+ my ($self, $f, $cfgname, $p) = @_;
+ my $cfgtype =
+ ($self-{type} eq exe)
+ ?'Application'
+ :($self-{type} eq dll?'DynamicLibrary':'StaticLibrary');
+
+ print $f EOF;
+ PropertyGroup
Condition='\$(Configuration)|\$(Platform)'=='$cfgname|$self-{platform}'
Label=Configuration
+ ConfigurationType$cfgtype/ConfigurationType
+ UseOfMfcfalse/UseOfMfc
+ CharacterSetMultiByte/CharacterSet
+ WholeProgramOptimization$p-{wholeopt}/WholeProgramOptimization
+ PlatformToolsetv110/PlatformToolset
+ /PropertyGroup
+ EOF
+ }
+
1;
diff -Napcdr -x .git postgresql/src/tools/msvc/Solution.pm
postgresql_dev/src/tools/msvc/Solution.pm
*** postgresql/src/tools/msvc/Solution.pm Wed Mar 14 23:14:28 2012
--- postgresql_dev/src/tools/msvc/Solution.pm Wed Mar 14 23:58:58 2012
*** sub new
*** 645,648
--- 645,672
return $self;
}
+ package VS2012Solution;
+
+ #
+ # Package that encapsulates a Visual Studio 2012 solution file
+ #
+
+ use Carp;
+ use strict;
+ use warnings;
+ use base qw(Solution);
+
+ sub new
+ {
+ my $classname = shift;
+ my $self = $classname-SUPER::_new(@_);
+ bless($self, $classname);
+
+ $self-{solutionFileVersion} = '12.00';
+ $self-{vcver} = '11.00';
+ $self-{visualStudioName} = 'Visual Studio 2012';
+
+ return $self;
+ }
+
1;
diff -Napcdr -x .git postgresql/src/tools/msvc/VSObjectFactory.pm
postgresql_dev/src/tools/msvc/VSObjectFactory.pm
*** postgresql/src/tools/msvc/VSObjectFactory.pmTue Jan 3 15:56:06 2012
--- postgresql_dev/src/tools/msvc/VSObjectFactory.pmWed Mar 14 23:59:03 2012
*** sub CreateSolution
*** 41,46
--- 41,50
{
return new VS2010Solution(@_);
}
+ elsif ($visualStudioVersion eq '11.00')
+ {
+ return new VS2012Solution(@_);
+ }
else
{
croak The requested Visual Studio version is not supported.;
*** sub CreateProject
*** 68,73
--- 72,81
{
return new VC2010Project(@_);
}
+ elsif ($visualStudioVersion eq '11.00')
+ {
+ return new VC2012Project(@_);
+ }
else
{
croak The requested Visual Studio version is not supported.;
*** sub DetermineVisualStudioVersion
*** 105,115
sub _GetVisualStudioVersion
{
my($major, $minor) = @_;
! if ($major 10)
{
carp
The determined version of Visual Studio is newer than the latest supported
version. Returning the latest supported version instead.;
! return '10.00';
}
elsif ($major 6)
{
--- 113,123
sub _GetVisualStudioVersion
{
my($major, $minor) = @_;
! if ($major 11)
{
carp
The determined version of Visual Studio is newer than the latest supported
version. Returning the latest supported version instead.;
! return '11.00';
}
elsif ($major 6)
{
diff -Napcdr -x .git postgresql/src/tools/msvc/build.pl
postgresql_dev/src/tools/msvc/build.pl
*** postgresql/src/tools/msvc/build.pl Tue Jan 3 15:56:06 2012
--- postgresql_dev/src/tools/msvc/build.pl Thu Mar 15 00:12:25 2012
*** elsif ($ARGV[0] ne RELEASE)
*** 50,56
# ... and do it
! if ($buildwhat and $vcver eq '10.00')
{
system(msbuild $buildwhat.vcxproj /verbosity:detailed
/p:Configuration=$bconf);
}
--- 50,56
# ... and do it
! if ($buildwhat and $vcver = 10.00)
{
system(msbuild $buildwhat.vcxproj /verbosity:detailed
/p:Configuration=$bconf);
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 9.2 Beta: intersection of daterange
I'm currently doing some tests on range types: tests=# SELECT int8range(5,15) * int8range(10,20) AS intersection; intersection -- [10,15) (1 Zeile) tests=# tests=# SELECT '[2010-03-15,2010-05-22)'::daterange * '[2010-01-04,)'::daterange AS intersection; intersection - [2010-03-15,2010-05-22) (1 Zeile) Does the second query trigger a bug or am I misunderstanding something? I would expect [2010-01-04,2010-05-22) as result. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.2 Beta: intersection of daterange
Misa Simic wrote: I think result is ok... 2010-01-04 is not inside first range... Staring at my query for five minutes obviously didn't prevent me from creating that noise. I meant to query SELECT '[2010-03-15,2010-05-22)'::daterange * '[2010-04-01,)'::daterange AS intersection; which gives the expected result. Sorry for the noise! Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review of VS 2010 support patches
Andrew Dunstan wrote: Can you narrow down exactly what in that commit broke VS 2010? Are there any compiler warnings? I was able to nail down the problem. Running the regression tests (vcregress check) gives the following messages: snip == creating temporary installation== == initializing database system == == starting postmaster== pg_regress: postmaster did not respond within 60 seconds Examine src/test/regress/log/postmaster.log for the reason /snip postmaster.log shows the following messages: snip LOG: database system was shut down at 2011-12-28 22:09:46 CET LOG: database system is ready to accept connections LOG: autovacuum launcher started LOG: incomplete startup packet /snip with the line LOG: incomplete startup packet repeated several times afterwards. The problem seems to be related to an invalid socket error constant. EWOULDBLOCK gets expanded to 140 with commit 1a0c76c32fe470142d3663dd84ac960d75a4e8db applied whereas it got expanded to 10035L before. Adding the following code to src/include/port/win32.h restores the former (running) behaviour : snip #if _MSC_VER = 1600 #pragma warning(disable:4005) #define EWOULDBLOCK WSAEWOULDBLOCK #endif /snip But according to the winsock docs this minimal invasive surgery isn't really appropriate (at least for visual c). http://msdn.microsoft.com/en-us/library/windows/desktop/ms737828(v=vs.85).aspx It appears that VS 2010 and Windows SDK 7.1 now have an extended errno.h that defines quite a few of the E* constants: snip /* POSIX SUPPLEMENT */ #define EADDRINUSE 100 #define EADDRNOTAVAIL 101 [...] #define ETXTBSY 139 #define EWOULDBLOCK 140 /snip Here we probably run into the conflict that winsock2.h has always been warning about: snip /* * Windows Sockets errors redefined as regular Berkeley error constants. * These are commented out in Windows NT to avoid conflicts with errno.h. * Use the WSA constants instead. */ #if 0 #define EWOULDBLOCK WSAEWOULDBLOCK [...] #define ESTALE WSAESTALE #define EREMOTE WSAEREMOTE #endif /snip A possible solution would be to use something like PGEWOULDBLOCK and similiar constants wherever socket errors are used and set them to the WSAE* constants on windows and the E* constants on other platforms. Anyhow, this would be ways beyond the scope of my patch and there will probably be a better solution to be suggested from a real C hacker. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review of VS 2010 support patches
Brar Piening wrote: I have to admit that it's currently broken (it builds but fails during regression tests becuse it can't connect) when building with Visual Studio 2010 or Windows SDK 7.1 because of commit 1a0c76c32fe470142d3663dd84ac960d75a4e8db (Enable compiling with the mingw-w64 32 bit compiler). It seems like VS 2010 has a few of the E... constants in src/include/port/win32.h already defined, but obviously in a way that breaks postgres. Because of my missing experience and as I don't have a Mingw64 build environment I don't feel like I could fix that without breaking anythig else. I'd like to add that I'm certainly willing to test suggested fixes or patches in my VS 2010 build environment. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review of VS 2010 support patches
Andrew Dunstan wrote: In the absence of reaction to this I've marked the patch as waiting on author, but if/when I have time I'll work on rearranging things as above. Sorry for my non-reaction. I'm currently trying to find some time window in my before chrismas schedule but it seems like I can't guarantee anything. Anyhow I'll try to make it happen within this year. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review of VS 2010 support patches
Magnus Hagander wrote: I'd vote for whatever matches the general perl pest practices at this time. I didn't kow the perl pest practices until now but as the PostgreSQL community is more into C I think I know what you mean ;-) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review of VS 2010 support patches
Andrew Dunstan wrote:
Some minor nitpicks:
Do we really need to create all those VSProject.pm and
VSSolution.pm files? They are all always included anyway. Why not
just stash all the packages in Solution.pm and Project.pm?
We certainly don't *need* them.
Having different files separates the tasks of generating different
target file formats into different source files. In my opinion this
makes it easier to find the code that is actually generating the files
that get used in a specific build environment.
While the VSSolution.pm and VC200nProject.pm files are indeed not
much more than stubs that could eventually be extended in future (and
probably never will) VC2010Project.pm contains the whole code for
generating the new file format which would significantly bloat up the
code in Project.pm that currently contains the common code for
generating the old file formats.
Anyhow - this is just my opinion and my intention is to help improving
the Windows build process and not forcing my design into the project.
Also, instead of doing this in Mkvcbuild.pm:
my $vsVersion = VSObjectFactory::DetermineVisualStudioVersion();
$solution = VSObjectFactory::CreateSolution($vsVersion, $config);
why not just add use VSObjectFactory; at the top of the file and
import these into the current namespace, just as we do for pretty much
everything else?
Yes - my way (singleton, clean namespace) is probably overengineering in
this context.
There are some stylistic things that aren't the way I usually do
things (use of named instead of anonymous file handles, use of
heredocs instead of qq{} style quotes) and that I would prefer done
differently, but those are more matters of taste than substance.
Please go ahead and change it to whatever style you prefer. There is
certainly more than one way to style it ;-)
I also generally dislike composing XML by non-formal means, as it can
be quite error prone and often leads to errors in unforeseen corner
cases. But in this case we certainly don't want to impose an extra
requirement on some perl XML module, and it would make this code
terribly verbose, so we just have to hope we get it right :-)
I actually had a look into the default ActivePerl docs to find out
whether there is a better way for generating xml, but as there is no
XML-generator package in the default distribution I decided not to
introduce a new dependency.
Thanks for your feedback.
Regards,
Brar
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is there a good reason we don't have INTERVAL 'infinity'?
Josh Berkus wrote: Hackers, Is there a reason why INTERVAL 'infinity' is not implemented? That is, an interval which is larger than all defined intervals, and which added to any timestamp turns it into 'infinity'. Or is it just Round TUITs? Probably the latter. There is even a function |isfinite(interval)| which doesn't seem to do anything useful. See complaint in http://archives.postgresql.org/message-id/200101241913.f0ojduu45...@hub.org Although the operation used in this complaint isn't obviously defined there certainly are operations that are defined like infinity + infinity = infinity. See http://de.wikipedia.org/wiki/Unendlichkeit#Analysis (Sorry for linking the german wikipedia - the english text is ways less verbose on this.) Regards, Brar
Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
thready wrote:
[...]
I don't know how to apply this patch. What's the exe that runs this
patch? Will it ask me where the source folder root is when I run it?
As the archives seem to be unreachable at the moment I'm copying text
from the following message which I would otherwise ask you to read:
http://archives.postgresql.org/message-id/4e2813ec.2050...@gmx.de
CITATION
In short (for the records): download and install msysgit from
http://code.google.com/p/msysgit/downloads/list
Open git bash and cd into an empty directory like:
cd c:
mkdir pgdev
cd pgdev
Clone the postgresql repository:
git clone git://git.postgresql.org/git/postgresql.git
cd postgresql
Copy the patch (the part with the strange perl-like text of the
message) from
http://archives.postgresql.org/message-id/4e14fd1a.8080...@gmx.de and
save it to a file (like VS2010v9.patch) which you put into the directory
which contains your newly created repository (c:\pgdev).
Apply the Patch:
patch -Ec -p 1 -i ../VS2010v9.patch
(which doesn't seem to apply cleanly anymore which will break things for
you - but I currently have no time to fix it)
Put bison and flex into your path like:
echo \$ENV{PATH}=\$ENV{PATH} . ';C:\Program Files (x86)\Git\bin';
src/tools/msvc/buildenv.pl
(you might have to adopt the path)
Open a Visual Studio 2010 command prompt and cd into the src/tools/msvc
directory of your repository like:
cd C:\pgdev\postgresql\src\tools\msvc
Start the build:
build.bat
/CITATION
Please use the commitfest app
(https://commitfest.postgresql.org/action/patch_view?id=523) to find out
about the current state of the patch and to get the latest version.
If you have problems applying the patch when copied from the archives
(v10 -
http://archives.postgresql.org/message-id/4e837b20.4020...@gmx.de),
please drop me a line and I'll send you the latest version off list.
Regards,
Brar
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Commitfest app not exporting moved to another commitfest to rss
I use rss to follow up on patches that I'm interested in and it's the second time I was wonering where my patch has gone in the commitfest app due to $Topic. Is this a known limitation? If yes: Is there a way to change this? If yes: Can/shall I help? If yes: Where should I start? Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest app not exporting moved to another commitfest to rss
Brar Piening wrote: I use rss to follow up on patches that I'm interested in and it's the second time I was wonering where my patch has gone in the commitfest app due to $Topic. Just after pushing the send button my RSS-feed got updated and contained the relevant information. Sorry for the noise! I don't actually understand the delay in my feed getting updated despite the fact that I'm regularly updating it on my side. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review of VS 2010 support patches
Brar Piening wrote: The attached patch includes documentation changes and excludes my versions of pgbison.pl and pgflex.pl which have been replaced by Andrews' versions that are already commited. Building current head today I noticed that the patch doesn't apply cleanly anymore. Attached is a new version. Regards, Brar diff -Napcdr -x .git postgresql/doc/src/sgml/install-windows.sgml postgresql_dev/doc/src/sgml/install-windows.sgml *** postgresql/doc/src/sgml/install-windows.sgmlWed Sep 28 19:23:58 2011 --- postgresql_dev/doc/src/sgml/install-windows.sgmlWed Sep 28 19:32:22 2011 *** *** 20,29 There are several different ways of building PostgreSQL on productnameWindows/productname. The simplest way to build with Microsoft tools is to install a supported version of the ! productnameMicrosoft Platform SDK/productname and use the included compiler. It is also possible to build with the full ! productnameMicrosoft Visual C++ 2005 or 2008/productname. In some cases ! that requires the installation of the productnamePlatform SDK/productname in addition to the compiler. /para --- 20,29 There are several different ways of building PostgreSQL on productnameWindows/productname. The simplest way to build with Microsoft tools is to install a supported version of the ! productnameMicrosoft Windows SDK/productname and use the included compiler. It is also possible to build with the full ! productnameMicrosoft Visual C++ 2005, 2008 or 2010/productname. In some cases ! that requires the installation of the productnameWindows SDK/productname in addition to the compiler. /para *** *** 69,100 sect1 id=install-windows-full titleBuilding with productnameVisual C++/productname or the ! productnamePlatform SDK/productname/title para PostgreSQL can be built using the Visual C++ compiler suite from Microsoft. These compilers can be either from productnameVisual Studio/productname, productnameVisual Studio Express/productname or some versions of the ! productnamePlatform SDK/productname. If you do not already have a productnameVisual Studio/productname environment set up, the easiest ! way us to use the compilers in the productnamePlatform SDK/productname, which is a free download from Microsoft. /para para ! PostgreSQL supports the compilers from ! productnameVisual Studio 2005/productname and ! productnameVisual Studio 2008/productname. When using the Platform SDK ! only, or when building for 64-bit Windows, only ! productnameVisual Studio 2008/productname is supported. ! productnameVisual Studio 2010/productname is not yet supported. ! /para ! ! para ! When building using the productnamePlatform SDK/productname, versions ! 6.0 to 7.0 of the SDK are supported. Older or newer versions will not work. ! In particular, versions from 7.0a and later will not work, since ! they include compilers from productnameVisual Studio 2010/productname. /para para --- 69,94 sect1 id=install-windows-full titleBuilding with productnameVisual C++/productname or the ! productnameMicrosoft Windows SDK/productname/title para PostgreSQL can be built using the Visual C++ compiler suite from Microsoft. These compilers can be either from productnameVisual Studio/productname, productnameVisual Studio Express/productname or some versions of the ! productnameMicrosoft Windows SDK/productname. If you do not already have a productnameVisual Studio/productname environment set up, the easiest ! way is to use the compilers in the productnameWindows SDK/productname, which is a free download from Microsoft. /para para ! PostgreSQL is known to support compilation using the compilers shipped with ! productnameVisual Studio 2005/productname to ! productnameVisual Studio 2010/productname (including Express editions), ! as well as standalone Windows SDK releases 6.0 to 7.1. ! 64-bit PostgreSQL builds are only supported with ! productnameMicrosoft Windows SDK/productname version 6.0a and above or ! productnameVisual Studio 2008/productname and above. /para para *** *** 104,114 productnameCygwin/productname present in your system PATH. Also, make sure you have all the required Visual C++ tools available in the PATH. In productnameVisual Studio/productname, start the ! applicationVisual Studio Command Prompt/application. In the ! productnamePlatform SDK/productname, start the ! applicationCMD shell/application listed under the SDK on the Start Menu. If you wish to build a 64-bit version, you must use the 64-bit version of the command, and vice versa. All commands should be run from the filenamesrc\tools\msvc/filename directory. /para --- 98,110 productnameCygwin/productname present in your system PATH. Also, make sure
Re: [HACKERS] Support UTF-8 files with BOM in COPY FROM
Tom Lane wrote:
Putting a BOM into UTF8 data is flat out invalid per spec --- the fact
that Microsloth does it does not make it standards-conformant.
Could you share a pointer to the spec?
All I've ever heard is that a BOM is optional for UTF-8 but not forbidden.
The Unicode FAQ (http://unicode.org/faq/utf_bom.html#BOM) states that
some recipients of UTF-8 encoded data do not expect a BOM.
Postgres obviously belongs to those recipients.
That's why all my psql-scripts transferring data from MSSQL to Postgres
need a '\! perl -CD -pi.orig -e tr/\x{feff}//d C:/datafile.txt'
before feeding data into COPY TO.
Reading it tolerantly and writing it on user request is probably the way
that would help most users.
Regards,
Brar
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Support UTF-8 files with BOM in COPY FROM
Tom Lane wrote:
Yeah, that's a reasonable argument for rejecting the patch altogether.
I'm not qualified to decide whether it outweighs the we need to be able
to read Notepad output argument.
Actually it's not only notepad.
I quite often find myself doing something like the following when moving
data from MSSQL to PostgreSQL.
\echo Fetching data for table patient
\! sqlcmd -S DBSERVER -d DATABASE -E -f 65001 -o C:/datafile.txt -h -1
-W -s | -Q SET NOCOUNT ON; SELECT * FROM my_table;
\! perl -CD -pi.orig -e tr/\x{feff}//d C:/datafile.txt
\echo Importing data into table patient
\copy my_table FROM 'C:/datafile.txt' WITH DELIMITER '|' NULL 'NULL'
Regards,
Brar
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Support UTF-8 files with BOM in COPY FROM
Robert Haas wrote: The thing that makes me doubt that is this comment from Tatsuo Ishii: TI COPY explicitly specifies the encoding (to be UTF-8 in this case). So TI I think we should not regard U+FEFF as BOM in COPY, rather we should TI regard U+FEFF as ZERO WIDTH NO-BREAK SPACE. If a BOM is confusable with valid data, then I think recognizing it and discarding it unconditionally is no good - you could end up where COPY OUT, TRUNCATE, COPY IN changes the table contents. Citing from the Unicode FAQ again: Q: Where is a BOM useful? A: A BOM is useful at the beginning of files that are typed as text, but for which it is not known whether they are in big or little endian format—it can also serve as a hint indicating that the file is in Unicode, as opposed to in a legacy encoding and furthermore, it act as a signature for the specific encoding form used. I think that the major hint in the answer is beginning of files. To correctly handle a BOM you need to be sure to be in the context of files that have defined bounds (especially a *beginning*) you can't properly handle a BOM in arbitrary streams. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Support UTF-8 files with BOM in COPY FROM
Tom Lane wrote: Note that the reference to byte order betrays the implicit context assumption: that we're talking about UTF16 or UTF32 representation. Note that there is no implicit context assumption in the Unicode FAQ. It's equally covering UTF-8, UTF-16 and UTF-32. Another quote: Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order? A: Yes, UTF-8 can contain a BOM. However, it makes /no/ difference as to the endianness of the byte stream. UTF-8 always has the same byte order. An initial BOM is /only/ used as a signature --- an indication that an otherwise unmarked text file is in UTF-8. Note that some recipients of UTF-8 encoded data do not expect a BOM. Where UTF-8 is used/transparently/ in 8-bit environments, the use of a BOM will interfere with any protocol or file format that expects specific ASCII characters at the beginning, such as the use of #! of at the beginning of Unix shell scripts. BOM is useless in UTF8, no matter what Microsoft thinks. Any tool that relies on it to detect UTF8 data has to have a workaround for overriding that detection, or it's broken to the point of uselessness. This kind of brokenness is currently existing the other way around (see my reference to the perl script I' using to work aound it). Note also that I'm not citing a Microsoft FAQ but the Unicode FAQ. I'm also not trying to convert Postgres into a Microsoft tool (I'm pretty happy it isn't) but I'm pointing to existing compatibility issues on a Platform that others have decided to support. Belonging to the huge group of users who have little or no choice in what OS they are using and being from a country where plain ASCII isn't enough to cover all existing characters this is probably fair. It's a pity that the Unicode standard actually allows something that can cause problems but blaming the non-platform again doesn't solve the existing issues. Regards, Brar
Re: [HACKERS] Support UTF-8 files with BOM in COPY FROM
Brar Piening wrote: It's a pity that the Unicode standard actually allows something that can cause problems but blaming the non-platform again doesn't solve the existing issues. To put in a more humoruos but actually correct way: M$ has found a standard conforming way of preventing users to migrate data from MSSQL to PostgreSQL. Do you want to work arond it? Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review of VS 2010 support patches
Original Message Subject: Re: [HACKERS] Review of VS 2010 support patches From: Magnus Hagander mag...@hagander.net To: Brar Piening b...@gmx.de Date: 08.07.2011 11:38 Sorry for the late response - I've been on a wedding this weekend. Something is strange here. Did you run perltidy with the exact parameters documented in the README file? Yes - I usually even copy paste it from the README as perltidy -b -bl -nsfs -naws -l=100 -ole=unix *.pl *.pm (pasted once more) is hard to remember and takes a while to type. If so, perltidy seems to be version- or platform- dependent. I ran it, and got a slightly different patch. It's not big differences, but the simple fact that perltidy doesn't always generate the same result is annoying. Can you run it again, and make sure you get the exact same diff? So that it wasn't accidentally run off the wrong version or something? I just rechecked that applying my two patches vs. applying my two patches + running the above perltidy command gives no difference (0 byte patch). I've attached the differences between your perltidy and my perltidy run. I'm using (perltidy -v): This is perltidy, v20090616 I'm currently using (perl -v): This is perl 5, version 14, subversion 1 (v5.14.1) built for MSWin32-x64-multi-thread and (perltidy -v): This is perltidy, v20101217 But I've just recently upgraded to the latest Perl version. The patch has been produced using some 5.12.? ActivePerl and it's corresponding perltidy version which (whatever it was) obviously produced the same result for me. http://perltidy.sourceforge.net/ChangeLog.html#2010_12_17 doesn't seem to have any Information which would explain our different patches. Strange... Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review of VS 2010 support patches
Original Message
Subject: Re: [HACKERS] Review of VS 2010 support patches
From: Craig Ringer cr...@postnewspapers.com.au
To: Brar Piening b...@gmx.de
Date: 07.07.2011 16:44
Frankly, I suggest leaving these tests for the buildfarm to sort out.
I don't see any sign of build process issues; they all build fine, and
it's pretty darn unlikely that build changes would cause them to break
at runtime. Windows buildfarm coverage looks pretty decent these days.
As I had no Idea whether the buildfarm is even ready to work with VS
2010 I set out and tested it.
I can happily tell you that I have just now completed my first
successful buildfarm run using the attached build-farm.conf
Regards,
Brar
# -*-perl-*- hey - emacs - this is a perl file
=comment
Copyright (c) 2003-2010, Andrew Dunstan
See accompanying License file for license details
=cut
package PGBuild;
use strict;
use vars qw(%conf);
# use vars qw($VERSION); $VERSION = 'REL_4.5';
my $branch;
{
no warnings qw(once);
$branch = $main::branch;
}
%conf =
(
scm = 'git', # or 'cvs'
scmrepo = undef , # default is community repo for either type
scm_url = undef, # webref for diffs on server - use default for
community
# git_reference = undef, # for --reference on git repo
# cvsmethod = 'update', # or 'export'
use_git_cvsserver = undef, # or 'true' if repo is a git cvsserver
make = 'make', # or gmake if required. can include path if necessary.
tar_log_cmd = undef, # default is tar -z -cf runlogs.tgz *.log
# replacement must have the same effect
# must be absolute, can be either Unix or Windows style for MSVC
build_root = 'P:\PgBuildFarm\build_root',
use_vpath = undef, # set true to do vpath builds
# path to directory with auxiliary web script
# if relative, the must be relative to buildroot/branch
# possibly only necessary now on WIndows, if at all
aux_path = ../..,
keep_error_builds = 0,
target = http://www.pgbuildfarm.org/cgi-bin/pgstatus.pl;,
upgrade_target = http://www.pgbuildfarm.org/cgi-bin/upgrade.pl;,
animal = CHANGEME,
secret = CHANGEME,
# change this to a true value if using MSVC, in which case also
# see MSVC section below
using_msvc = 1,
# if force_every is a scalar it will be used on all branches, like this
# for legacy reasons:
# force_every = 336 , # max hours between builds, undef or 0 =
unforced
# we now prefer it to be a hash with branch names as the keys, like
this
#
# this setting should be kept conservatively high, or not used at all
-
# for the most part it's best to let the script decide if something
# has changed that requires a new run for the branch.
#
# an entry with a name of 'default' matches any branch not named
force_every = {
# HEAD = 48,
# REL8_3_STABLE = 72,
# default = 168,
},
# alerts are triggered if the server doesn't see a build on a branch
after
# this many hours, and then sent out every so often,
alerts = {
#HEAD = { alert_after = 72, alert_every = 24 },
# REL8_1_STABLE = { alert_after = 240, alert_every = 48 },
},
print_success = undef,
# pattern for files whose changes do NOT trigger a build
# use qr[/(doc|po)/] to ignore changes to docs and po files
(recommended)
# undef means don't ignore anything.
trigger_filter = qr[/(doc|po)/] ,
# settings for mail notices - default to notifying nobody
# these lists contain addresses to be notified
# must be complete email addresses, as the email is sent from the
server
mail_events =
{
all = [], # unconditional
fail = [], # if this build fails
change = [], # if this build causes a state change
green = [], # if this build causes a state change to/from OK
},
# env settings to apply within build/report process
# these settings will be seen by all the processes, including the
# configure process.
build_env =
{
# use a dedicated cache for the build farm. this should give us
# very high hit rates and slightly faster cache searching.
CCACHE_DIR = /home/andrew/pgfarmbuild/ccache/$branch,
### use these settings for CYGWIN
# CYGWIN = 'server',
# MAX_CONNECTIONS = '3',
### set this if you need a proxy setting for the
# outbound web transaction that reports the results
# BF_PROXY = 'http
Re: [HACKERS] Review of VS 2010 support patches
Original Message Subject: Re: [HACKERS] Review of VS 2010 support patches From: Craig Ringer cr...@postnewspapers.com.au To: Brar Piening b...@gmx.de Date: 06.07.2011 14:56 It turns out that VS2010v8.patch is also attached to the same message. Not that you'd know it from the ... interesting ... way the web ui presents attachments. Sorry I missed it. Yes I've also noticed that the web ui has somewhat screwed up the two patches attached to my email. This seems avoidable as one can see in http://archives.postgresql.org/pgsql-hackers/2011-07/msg00140.php but I don't know how. [...] That makes sense. Do you want to integrate those in a v9 revision along wiht a docs patch? I certainly could. But as those files are Andrew's work which isn't really related to VS2010 build and could as well be commited seperately I don't want to take credit for it. I'll remove my versions from the patch (v9 probably) if those files get commited. [...] For the docs, it might be worth being more specific about the visual studio versions. [...] Thanks for the hints I'll consider then once I'll get started with the docs. [...] Now I just need to test with Windows SDK 6.0 (if I can even get it to install on win7 x64; the installer keeps crashing) as that's the SDK shipped with Visual Studio 2005 SP1 . Actually I've also successfully tested an empty (no config.pl) 32-bit build using Visual Studio 2005 RTM. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] %ENV warnings during builds
schrieb Andrew Dunstan: Hmm, I missed that you had done this. Here are two replacement perl scripts I knocked up, but haven't yet tested. One of the things about them is that they remove knowledge of particular .l and .y files. and instead get the required invocation options from the relevant Makefiles. I think that's a lot better than the horrid hackery we have in the batch files. Yep - they certainly look ways less messy than what I've created as a simple perl version of the batch files. But I get Undefined subroutine main::dirname called at src\tools\msvc\pgflex.pl line 36. if I try to build with them. I'll update my patch to remove my versions once they are fixed and commited. Meanwhile you might need to create (at least temporarily) .bat wrappers as the unpatched msvc build sytem expects them to be in place. I could also extract those parts from my patch but we should probably go the wohle way now to get it in shape and get it commited. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review of VS 2010 support patches
Original Message
Subject: Review of VS 2010 support patches
From: Craig Ringer cr...@postnewspapers.com.au
To: PG Hackers pgsql-hackers@postgresql.org, Brar Piening b...@gmx.de
Date: 05.07.2011 14:25
I haven't had any reply to my email to Brar, so there are a few
details (like whether x64 builds were tested and how x64 required
libraries were built) I could use, but what I've got done so far seems
fine.
I've replied on-list see:
http://archives.postgresql.org/pgsql-hackers/2011-07/msg00066.php
Seems like i've got fooled by reply to list being thunderbird's
default for mailing lists once more. Sorry for that one.
The patch (VS2010v7.patch) seems to mix significant changes with
whitespace fixes etc.
Current version (VS2010v8.patch) which I've submitted on-list about one
month ago has fixed this as per Tom Lane's comment.
See: http://archives.postgresql.org/message-id/4dedb6ee.9060...@gmx.de
pgflex.pl and pgbison.pl
=
pgflex.pl and pgbison.pl are a big improvement over the horrid batch
files, but are perhaps too little a translation. There's no need for
the big if(string) then (otherstring) stuff; it can be done much more
cleanly by storing a simple hash of paths to options and doing a file
extension substitution to generate the output filenames. The hash only
needs to be populated for files that get processed with non-default
options, so for pgflex all you need is:
%LEX_OPTS = { 'src\backend\parser\scan.c' - '-CF' };
I can send adjusted versions of pgflex.pl and pgbison.pl that
I think the approach Andrew Dunstan chose (parsing the Makefiles) is
even more flexible and future proof. We should probably be using his
versions.
See: http://archives.postgresql.org/pgsql-hackers/2011-07/msg00140.php
and http://archives.postgresql.org/pgsql-hackers/2011-07/msg00185.php
DOCUMENTATION
===
I didn't notice any documentation updates to reflect the fact that
Visual Studio 2010 is now supported. It'd be a good idea to change
install-windows-full.html (or the source of it, anyway) to mention VS
2010 support.
Yep - a clear leftover. I've never written any SGML but I'll try to come
up with something as soon as as I've got the doc build working on my system.
I'm not sure if I'll be able to get 64-bit copies of all the optional
libraries built, so it may be a more minimal build. It'll include at
least zlib, plperl and plpython 64-bit support, though. Information
from Briar about whether he built for 64-bit and if so how he got his
libraries built would help.
Actually my default builds are 64-bit builds as my PC is Win7 x64 and
I'm using 64-Bit versions for my PostgreSQL work.
As you noted, the availability of 64-bit libraries was the limiting
factor for more extensive testing but I haven't run into any Problems
with my default configuration (nothing but plperl) and some others I've
tried yet.
Regards,
Brar
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] %ENV warnings during builds
Original Message Subject: Re: [HACKERS] %'ENV warnings during builds From: Andrew Dunstan and...@dunslane.net To: Brar Piening b...@gmx.de Date: 05.07.2011 17:25 Try attached instead. I can confirm that this version of pgflex.pl works as expected in my environment. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] flex on win64 - workaround for flex: fatal internal error, exec failed
schrieb Craig Ringer:
I haven't managed to figure out exactly what's broken. For the benefit
of anyone else having problems like this or who might find this via a
search later, though: just install msys and use the current flex from
msys. It works perfectly in Pg's build environment and it's easy to
install, so you don't need to stuff around trying to get flex to work.
Grab mingw-get-inst from
http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/
and use it to install msys and the minimalist mingw. You won't be
using mingw, but it won't hurt you, and it's easier than installing
msys standalone.
Edit src\tools\msvc\buildenv.pl (or create it if necessary) and use it
to add C:\MinGW\msys\1.0\bin to your PATH. Adjust as appropriate if
your MinGW install dir was different. Eg:
$ENV{PATH}='C:\MinGW\msys\1.0\bin;' . $ENV{PATH};
As you might also want to use git for developing with postgres its
possible that all you need is already in place.
As I use msysgit my usual way of dealing with flex and bison
dependencies is putting $ENV{PATH}=$ENV{PATH} . ';C:\Program Files
(x86)\Git\bin'; into my buildenv.pl
Regards,
Brar
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
schrieb Craig Ringer: I'd appreciate it if you'd post the config.pl you're building with, mainly so I can see what libraries and optional features you are or are not using with your test builds. I've already posted it here: http://archives.postgresql.org/message-id/4dcda3cd.4030...@gmx.de Also: Have you been testing both 32-bit and 64-bit builds with VC 2010, or have you been doing 32-bit builds only? Both - but 32-bit was tested more extensively due to limited availability of 64-bit libraries. If you're testing 64-bit builds, how are you building/obtaining your dependencies, given that GnuWin32 doesn't carry 64-bit builds? Rebuilding GnuWin32 packages? Building from sources? I've only just got a 64-bit Windows dev environment set up so I'm new to building 64-bit Pg. Any issues you had to resolve to get the x64 libs built? No Issues im my minimal configuration. Perhaps someone who routinely does 64-bit builds could help out with a config.pl and some info from where to get the 64-bit libraries to build with. Thanks for reviewing! Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] %ENV warnings during builds
schrieb Magnus Hagander: I think you've stumbled on just about all the bits of the MSVC build system we haven't perlized. Maybe we should complete that task, and turn clean.bat, pgbison.bat and pgflex.bat into pure one-line wrappers. (It was done for builddoc just a few weeks ago). Yeah, give nthat you can't get anything useful done without perl anyway, I don't see any argument for keeping them at this point. I've already stumbled into this while preparing the VS2010 support and came to the same conclusion. In my VS2010 support patch I've already created perl replacements for those two and removed the batch files completely. Certainly those two could also stay around as mere wrappers but in my opinion they only mess up the directory without adding any relevant benefit. Typing perl pgbison.pl has no significant disadvantage over typing pgbison[.bat]. In my opinion it even makes clearer what really happens and leaves the beginner one step to recognize that the .bat files are mere wrappers. In addition the default ActiveState installations register themselves in a way that even let you type pgbison.pl Anyway - I don't have much passion for one way or the other and the wrappers should be easy to create by copy-pasting from one oft the wrappers already lying around. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] flexible array members
On Thu, 16 Jun 2011 22:49:45 +0300, Peter Eisentraut pete...@gmx.net wrote: This macro is provided by Autoconf and it appears to be using the standard's terminology. commit dbbba5279f66f95805c1e084e6f646d174931e56 refs/heads/master Author: Peter Eisentraut pete...@gmx.net Date: Thu Jun 16 22:39:09 2011 +0300 Periodically checking my VS2010 patch I noticed that this one broke Visual Studio builds. At least mine and chough http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=choughbr=HEAD in the build farm - I expect others to follow once they rebuild. error C2065: 'FLEXIBLE_ARRAY_MEMBER' : undeclared identifier error C2057: expected constant expression Regards, Brar
Re: [HACKERS] smallserial / serial2
On Tue, 7 Jun 2011 20:35:12 -0400, Mike Pultz m...@mikepultz.com wrote:
New patch attached.
Review for '20110607_serial2_v2.diff':
Submission review
- Is the patch in context diff format?
Yes.
- Does it apply cleanly to the current git master?
Yes.
- Does it include reasonable tests, necessary doc patches, etc?
It doesn't have any test but as it is really tiny and relies on the same
longstanding principles as serial and bigserial that seems ok.
It has documentation in the places where I'd expect it.
Usability review
- Does the patch actually implement that?
Yes.
- Do we want that?
Well, it depends whom you ask ;-)
Cons
Tom Lane: A sequence that can only go to 32K doesn't seem all that
generally useful
Pros
Mike Pultz (patch author): since serial4 and serial8 are simply
pseudo-types- effectively there for convenience, I’d argue that it
should simply be there for completeness
Robert Haas: We should be trying to put all types on equal footing,
rather than artificially privilege some over others.
Brar Piening (me): I'm with the above arguments. In addition I'd like
to mention that other databases have it too so having it improves
portability. Especially when using ORM.
Perhaps we can get some more opinions...
- Do we already have it?
No.
- Does it follow SQL spec, or the community-agreed behavior?
It has consistent behavior with the existing pseudo-types serial and
bigserial
- Does it include pg_dump support (if applicable)?
Not applicable.
- Are there dangers?
Not for the code base. One could consider it as a foot gun to allow
autoincs that must not exceed 32K but other databases offer even smaller
autoinc types (tinyint identity in MSSQL is a byte).
- Have all the bases been covered?
I guess so. A quick grep for bigint shows that it covers the same areas.
Feature test
- Does the feature work as advertised?
Yes.
- Are there corner cases the author has failed to consider?
Probably not.
- Are there any assertion failures or crashes?
No.
Performance review
- Does the patch slow down simple tests?
No.
- If it claims to improve performance, does it?
It doesn't claim anything about performance.
- Does it slow down other things?
No.
Coding review
- Does it follow the project coding guidelines?
Im not an expert in the project coding guidelines but it maches the
style of the surrounding code.
- Are there portability issues?
Probably not. At least not more than for smallint or serial.
- Will it work on Windows/BSD etc?
Yes.
- Are the comments sufficient and accurate?
Self explanatory - no comments needed.
- Does it do what it says, correctly?
Yes.
- Does it produce compiler warnings?
No.
- Can you make it crash?
No
Architecture review
- Is everything done in a way that fits together coherently with other
features/modules?
Yes.
- Are there interdependencies that can cause problems?
Interdependencies exist with sequences and the smallint type. No
problems probable.
Review review
- Did the reviewer cover all the things that kind of reviewer is
supposed to do?
I tried to look at everything and cover everthing but please consider
that this is my first review so please have a second look at it!
Regards,
Brar
CREATE DATABASE smallserial_test_db;
\connect smallserial_test_db
CREATE TABLE test_smallserial
(
id smallserial NOT NULL PRIMARY KEY,
val integer NOT NULL
);
CREATE TABLE test_smallserial2
(
id serial2 NOT NULL PRIMARY KEY,
val integer NOT NULL
);
\d
DROP TABLE test_smallserial2;
\d test_smallserial
INSERT INTO test_smallserial (val)
VALUES(1),(2),(3);
SELECT * FROM test_smallserial;
TRUNCATE TABLE test_smallserial;
SELECT setval('test_smallserial_id_seq', 1, false);
INSERT INTO test_smallserial (val)
SELECT * FROM generate_series(1,32767);
SELECT * FROM test_smallserial LIMIT ALL OFFSET 32764;
TRUNCATE TABLE test_smallserial;
SELECT setval('test_smallserial_id_seq', 1, false);
INSERT INTO test_smallserial (val)
SELECT * FROM generate_series(1,32768);
\connect postgres
DROP database smallserial_test_db;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] smallserial / serial2
On Wed, 8 Jun 2011 19:29:42 -0400, Robert Haas robertmh...@gmail.com wrote: You should also change the status to either Waiting on Author or Ready for Committer based on the content of the review. I think the latter would be appropriate since your review seems to have been favorable. Well - not being a review profi I was thinking that the appropriate status would be waiting for some more on list discussion about whether to include this or waiting for a more experienced reviewer to see if my review is ok (which could admittedly be the commiter). I've changed it. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] smallserial / serial2
On Wed, 20 Apr 2011 21:27:27 -0400, Mike Pultz m...@mikepultz.com wrote: Can this be added? Probably not - since it's not a complete patch ;-) I tried to test this one but was unable to find a complete version of the patch in my local mail archives and in the official archives (http://archives.postgresql.org/message-id/023001cbffc3$46f77840$d4e668c0$@mikepultz.com) Could you please repost it for testing? Regards, Brar
Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
On Fri, 13 May 2011 23:34:05 +0200, Brar Piening b...@gmx.de wrote: [...] I'd appreciate any reviews, tests or comments. As the current commitfest is getting more and more active recently i've rechecked my patch and updated it for code drift. No real changes. See http://www.piening.info/VS2010v7.patch The huge increase in size is due to running perltidy which also tidied up the new builddoc.pl which seems to have gotten in untidied. In a working Windows build environment all you have to do to test this patch is 1. Download Windows SDK v7.1 from http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6b6c21d2-2006-4afa-9702-529fa782d63b and install it 2. Apply the patch 3. Add your usual buildenv.pl and config.pl 4. Build Postgres using the Windows SDK 7.1 Command Prompt 5. Check if everything is working fine (build vcregress, ...) If someone with some more C skills than me could silence the warnings this would be a huge gain for build speed and testing. My previous attempts silenced the warnings but built a non-connectable backend. This one still stands as it is. Probably not a big issue for anyone of you. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
On Sun, 06 Feb 2011 23:06:21 +0100, Brar Piening b...@gmx.de wrote:
On Sun, 30 Jan 2011 21:26:22 +0100, Magnus Hagander
mag...@hagander.net wrote:
it's not something we should hold up the CF / release for.
I agree.
At least it should get some more testing besides mine.
[...]
Being somewhat short of time in the next weeks I'm at least willing to
rebase the patch on request and do some more testing or fix issues
someone else has detected before the next release (9.2?) goes beta.
After some months of being able to regularly compile current head using
Visual Studio 2010 compilers and some more tests I no longer see any
reason why this patch would change without external feedback.
I've tested the latest version (http://www.piening.info/VS2010v6.patch)
with the following config.pl for x86
$config-{perl} = 'C:\Perl'; # ActivePerl 5.8.9 Build 829
$config-{tcl} = 'C:\Tcl'; # ActiveState ActiveTcl 8.4.19.5
$config-{python} = 'C:\Python27'; # Python 2.7.1
$config-{openssl} = 'C:\openssl'; # openssl-1.0.0d
$config-{nls} = 'C:\Dev\gnuwin32'; # GetText 0.14.4
$config-{krb5} = 'C:\Dev\kfw-3-2-2-final';
$config-{xml} = 'C:\Dev\libxml2-2.7.7.win32';
$config-{xslt} = 'C:\Dev\libxslt-1.1.26.win32';
$config-{iconv} = 'C:\Dev\iconv-1.9.2.win32';
$config-{zlib} = 'C:\Dev\zlib125';
for x64 I've tested a less extensive configuration as it's still hard to
get the above libraries as x64 binaries.
I'd appreciate any reviews, tests or comments.
If someone with some more C skills than me could silence the warnings
this would be a huge gain for build speed and testing. My previous
attempts silenced the warnings but built a non-connectable backend.
Regards,
Brar
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
On Fri, 13 May 2011 21:52:47 -0400, Robert Haas robertmh...@gmail.com wrote: You probably want to add it here, then: https://commitfest.postgresql.org/action/commitfest_view/open I's been in the last commitfest and i've recently moved it to the current one already. See https://commitfest.postgresql.org/action/patch_view?id=523 Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Windows build issues
On Wed, 06 Apr 2011 22:07:52 +0200, Brar Piening b...@gmx.de wrote: On Wed, 06 Apr 2011 20:04:37 +0200, Brar Piening b...@gmx.de wrote: It's not ready yet but I'm prepared to get back to it as soon as there's some serious interest. I've updated the patch once again to reflect the fixes to pgbison.bat in my alternative pgbison.pl http://www.piening.info/VS2010v6.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Windows build issues
On Wed, 11 May 2011 06:15:08 +0200, Brar Piening b...@gmx.de wrote: I've updated the patch once again to reflect the fixes to pgbison.bat in my alternative pgbison.pl Actually not pgbison but pgflex -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Windows build issues
On Wed, 13 Apr 2011 10:45:25 +0200, Magnus Hagander mag...@hagander.net wrote: So per your experience, all we really need to do is to define what the *max* level of the Windows SDK we can use is, to make sure people don't get the VS2010 compiler instead? (And adding the note that VS2010 isn't supported with or without the platform sdk) Yes, v6.0-v7.0 will work, v7.0a(=VS 2010) and v7.1 will not work. Yeah, unfortunately it doesn't list which version of the compilers are included... Actually the VS 2010 compilers (and those of the associated Windows SDK's) work fine for building postgres. They produce quite a few additional warnings that I already mentioned (http://archives.postgresql.org/pgsql-hackers/2011-01/msg00118.php) but the product seems to work fine. The problem with VS 2010 (and the associated Windows SDK's) is the fact that MS dropped VCBuild.exe and now uses MSBuild.exe to build Visual C++ Projects so the generated build files don't work any longer. (see http://msdn.microsoft.com/en-us/library/bb531344.aspx) For the records (CSV): Version,Windows SDK Version Number,Build Number,Release Date,Building PostgreSQL Windows Vista Update .NET 3.0 SDK,v6.0,6.1.6000.16384.10,2007-03-22,will work (tested*) Included in Visual Studio 2008,v6.0a,??,2007-11-19,will work (untested) Windows Server 2008 .NET 3.5 SDK,v6.1,6.0.6001.18000.367,2008-02-05,will work (untested) Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP 1,v7.0,6.1.7600.16385,2009-07-24,will work (tested*) Included in Visual Studio 2010,v7.0a,6.1.7600.16385,2010-04-12,will not work yet (tested**) Microsoft Windows SDK for Windows 7 and .NET Framework 4,v7.1,7.1.7600.0.30514,2010-05-21,will not work yet (tested**) * builds and passes vcregress check with current git HEAD ** fails while trying to detect vcbuild version Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Windows build issues
On Tue, 12 Apr 2011 08:51:57 -0400, Andrew Dunstan and...@dunslane.net wrote: that's in the SDK? If not, I still think that should be our primary option - I certainly don't see how it's obsolete. (and you can, afaics, still get the platform sdk with the correct version of the compiler (non-vs2010), but I haven't tested it) Or did I miss something in this thread? Have we shown for sure that you can't build it with the compiler I haven't actually tried using the SDK alone. I'll try testing that on a cloud appliance when I get a chance, as I'm out of Windows boxes I can reasonable perturb. I do know you *need* the SDK for 64 bit builds with VSE 2008, as it doesn't include a 64 bit compiler. I've just built current git HEAD on a clean Windows XP virtual machine with only Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP 1 (the latest pre VS 2010 SDK) on it. It builds without problems (a few warnings) and passes vcregress check. VS or VS EXPRESS is probably not needed to build Postgres with any recent Windows SDK that includes compilers (= 6.0). This Wikipedia article might shed some more light on the MS SDK chaos: http://en.wikipedia.org/wiki/Microsoft_Windows_SDK Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Windows build issues
On Wed, 06 Apr 2011 20:27:22 +0300, Peter Eisentraut pete...@gmx.net wrote: I got it to build now. Here are is a list of notes that would make life easier for future generations: You might also want to have a look at my VS2010 patch as it already touches some of those issues. https://commitfest.postgresql.org/action/patch_view?id=523 It's not ready yet but I'm prepared to get back to it as soon as there's some serious interest. My personal plan is to get the good parts of it commited for 9.2 Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Windows build issues
On Wed, 06 Apr 2011 20:04:37 +0200, Brar Piening b...@gmx.de wrote: It's not ready yet but I'm prepared to get back to it as soon as there's some serious interest. I've rebased the patch in case somebody wants to try it. http://www.piening.info/VS2010v5.patch Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
On Sun, 30 Jan 2011 21:26:22 +0100, Magnus Hagander mag...@hagander.net wrote: it's not something we should hold up the CF / release for. I agree. At least it should get some more testing besides mine. I've set up virtual machines with VS 2003, VS 2005 Express, VS 2008 Express (+ my PC with VS 2010) for testing purposes but I didn't test all possible build paths with respect to the external libraries to include. While I didn't change much of the existing VS 2005/8 code I currently can't guarantee that the VS 2010 build will work for every possible external library one could include (yet I didn't stumble into any failure while testing) and still I could have broken some VS 2005/8 build path too. The patch could also be extended to automatically support building libpq when VS 2003 is detected or support other desireable features that aren't really in the context of supporting VS 2010. Being somewhat short of time in the next weeks I'm at least willing to rebase the patch on request and do some more testing or fix issues someone else has detected before the next release (9.2?) goes beta. If there's some pressure to support VS 2010 asap - please let me know and I'll see what I can do. Best regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
Hi, I initially considered this patch as a primer to start off some basic VS2010 support and not as something to be commited within the next few commitfests. As there seems to be at least some interest in this patch I refactored the code and did some more testing (actually found some weird issues with pgbison.bat and pgflex.bat and replaced them with perl variants). So there is now a third version of this patch at http://www.piening.info/VS2010v3.patch This time even with unix linefeeds ;-) On Sat, 15 Jan 2011 19:42:06 +0100, Magnus Hagander mag...@hagander.net wrote: Please make sure this goes on the commitfest page (https://commitfest.postgresql.org/action/commitfest_view?id=9), so it's not missed. I'll add it. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
On Tue, 18 Jan 2011 00:06:10 +0100, Brar Piening b...@gmx.de wrote: So there is now a third version of this patch at http://www.piening.info/VS2010v3.patch Forgot to run perltidy on it - fixed in http://www.piening.info/VS2010v4.patch Sorry! Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
Original-Nachricht
Datum: Mon, 3 Jan 2011 10:44:19 +0100
Von: Magnus Hagander mag...@hagander.net
An: Brar Piening b...@gmx.de
CC: pgsql-hackers@postgresql.org
Betreff: Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
This patch does not apply at all to my repository. Every single hunk
fails - I have a feeling it might have double line-ending encodings or
something like that?
double line-endings indeed!
Surprisingly only some of them (CRCRLF follow some CRLF's).
I was quite unsure about the best line endings for this patch so I probably
messed it up by converting them forth and back. Still I'm not sure if there's
something wrong with my git config - perhaps due to using git-external-diff (I
wasn't able to find win32 binaries for filterdiff).
Sorry about that!
perl -e open(INFILE, 'VS2010.patch');open(OUTFILE,
'VS2010_fixed.patch');binmode(INFILE);binmode(OUTFILE);$/=\\015\015\012\;$\=\\015\012\;while(INFILE){chomp;
print OUTFILE;}close(INFILE);close(OUTFILE)
fixes the problem.
Yeah, it looks that way - it's missing the ordering of the contrib
arrays. I'll run it once for that now, and then please rebase your
patch on top of that - makes it easier to review it.
If you still see any changes on top of that, then there's something
strange going on..
No that was probably all.
My patch - fixed as described above - should apply to your repository once
you've run perltidy.
I'll rebase the patch as soon as I return from work unless you tell me
otherwise.
Best Regards
Brar
--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
On Mon, 3 Jan 2011 10:44:19 +0100, Magnus Hagander mag...@hagander.net wrote: Yeah, it looks that way - it's missing the ordering of the contrib I'll run it once for that now, and then please rebase your patch on top of that - makes it easier to review it. The rebased patch can be grabbed from http://www.piening.info/VS2010v2.patch It's actually the same patch as before with the corrupted line-endings parsed out. git diff master VS2010 ../VS2010.patch reproduceabyl generates those on my (windows) system when I use git-external-diff configured as described in http://wiki.postgresql.org/wiki/Working_with_Git#Context_diffs_with_Git to produce context diffs. Unified diffs (git diff master VS2010 --no-ext-diff ../VS2010_unified.patch) only contain valid unix linfeeds Perhaps it has got something to do with core.autocrlf=true but I don't really care as long as I can get rid of it with one line of perl ;-) For the records I'm using $ git --version git version 1.7.3.1.msysgit.0 and the configuration of the postgresql repository is $ git config --list core.symlinks=false core.autocrlf=true color.diff=auto pack.packsizelimit=2g help.format=html http.sslcainfo=/bin/curl-ca-bundle.crt sendemail.smtpserver=/bin/msmtp.exe user.name=Brar Piening user.email=[myemail] core.repositoryformatversion=0 core.filemode=false core.bare=false core.logallrefupdates=true core.symlinks=false core.ignorecase=true core.hidedotfiles=dotGitOnly remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* remote.origin.url=git://git.postgresql.org/git/postgresql.git branch.master.remote=origin branch.master.merge=refs/heads/master diff.external=git-external-diff Best regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Visual Studio 2010/Windows SDK 7.1 support
Hi, i'v created a patch enables support for building PostgreSQL with Visual Studio 2010 or Microsoft Windows SDK for Windows 7 and .NET Framework 4 (Windows SDK 7.1). You can grab it from http://www.piening.info/VS2010.patch It only touches the .pl, .pm and .bat files in src/tools/msvc so it's relevant for Windows only (that's why i've left crlf line endings - is that actually ok or should I have converted them?). It's diffed against current head + running perltidy -b -bl -nsfs -naws -l=100 -ole=unix *.pl *.pm as described in the README file (which seems not to have been run before committing Mkvcbuild.pm the last time). It is problably neither the perfect way to introduce VS2010 support (my perl is better than my C but probably still not what you are used to) nor is it my way to try to make you officially support VS 2010. But perhaps it's something you could start with once you decide to upgrade the msvc toolchain. The patch is necessary because M$ got rid of vcbuild in favour of msbuild which uses a different build file format (*.vcxproj). It should support all use cases described in http://www.postgresql.org/docs/current/static/install-windows-full.html and builds in Windows SDK 7.0 (VS 2008 toolchain) x86 and x64 as well as Windows SDK 7.1 (VS 2010 toolchain) x86 and x64. The SDK 7.1 build produces tons of warnings which are mostly macro redefinitions of EIDRM, EMSGSIZE, EAFNOSUPPORT, EWOULDBLOCK, ECONNRESET, EINPROGRESS, ENOBUFS, EPROTONOSUPPORT, ECONNREFUSED and EOPNOTSUPP which seem to have found their way into errno.h finally. Cutting those out of src\include\pg_config_os.h and src\interfaces\libpq\win32.h makes the project build pretty clean. I resisted the temptation to parse them out of those files during Mkvcbuild::mkvcbuild as this should probably be handled by some preprocessor defines. The build result passes vcregress check. The pgsql.sln file also opens and builds in VS 2010. I hope it is of some use. Best regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Application name patch - v4
On Tue, 1 Dec 2009 09:59:17 +0100, Dave Page dp...@pgadmin.org wrote: I do see the argument that RESET ALL should revert user changes to application_name though, but I maintain they should reset to the value set at connection time, not to null. As has been pointed out already, other values set at connection time cannot be reset, so allowing that for application name does seem like a POLA violation. I'd like to support this Argument. As I understand this patch from http://archives.postgresql.org/pgsql-hackers/2009-10/msg00711.php it is intended to support some kind of feature like the SQL Server ...;Application Name=MyApp;... connection string value, making the name of the user level (or whatever) application name available at the Database/SQL level. I don't know about pgpool but as far as I know, some client side connection pooling implementations use one pool per connection string/url (.Net Data Providers, JDBC). They would probably want set the application_name in the startup message and will expect it to fall back to this value when calling RESET ALL (or what ever you like to be the command to go back to the values that were requested on connection startup) on recycling a connection from the pool. Any other solution would greatly complicate recycling of connections for per connection string pooling szenarios. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Contrib modules documentation online
Josh Berkus wrote: Having the contrib stuff in the main docs would remove one of the largest barriers to people knowing about the contrib features. Using PostgreSQL since Version 7.1.3 and reading this List since - I dont't know exactly but my current archives start in 2003 which was the last time I crashed my system - Albert's work is actually the first piece of contrib documentation I ever read. I always knew about contrib but as I haven't been missing any feature in the core distribution (well - actually I've been missing PL/R until it came up - but as you know it's not in contrib ;-) I never found time to dig into the contrib directories and README's. Now that I did I'm pretty amazed about the nice features I've never thought about. Further, you know we don't finish the docs until beta. Ever. Whenever you want - but do it. I also highly appreciate Albert's Idea/Work. Regards, Brar ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] .NET driver
Andrei Kovalevski schrieb: I have an experience with writing ODBC driver for PostgreSQL (https://projects.commandprompt.com/public/odbcng/). I would be happy to help community to improve .NET data provider. Please join the Npgsql Project at http://pgfoundry.org/projects/npgsql Francisco Figueiredo Jr. (fxjrlists[at]yahoo[dot]com[dot]br) will be happy about some new support. I once did some initial VS.Net 2002/3 integration but ran out of time half the way. It ist quite a bit of a pain as Microsoft has marked some important classes as sealed so you will see yourself reimplementing some wheels they already have implemented. Plus - as Merlin stated before - VS.Net/ADO.Net is a somewhat moving target for data provider implementations. Brar ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] .NET driver
Robert Treat schrieb: That would be nice. Of course none of this seems relevant to hackers, so I'd Your'e right - of course. But sometimes I wish 'hackers' would care a little more about their interfaces as the best backend can't be good without good interfaces and some of the PostgreSQL-interfaces don't reach the standard they are reaching for other databases. As a windows-user I still can't drag and drop a Dataset in VS.Net with Npgsql and I still have to build a single-threaded perl if i want to use DBD::Pg (I know about DBD::PgPP). I'm really happy with the backend right now and I could perhaps convince the decision makers at my job to use my personal favorite (in addition to MSSQL) - but not as long as the interface doesn't look like the one they are used to. If C# will not go above 5-10% in this http://www.postgresql.org/community/survey.13 statistic, PostgreSQL will not be able to cover all the markets it could. See: http://radar.oreilly.com/archives/2006/08/programming_language_trends_1.html As I know that this is is off-topic here I'm not going to discuss this any further on this list but I'll respond to personal mails or follow an invitation to 'advocacy' (to which I'm not yet subscribed) or any other convenient list. Regards, Brar ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
