Re: [HACKERS] NULL OR ZERO
Hello, Omar Bettin wrote: Probably I am on the wrong place but for me NULL on numbers means 0 or ZERO. I know about standards... You can easily convert NULLs to 0 in your queries - read about COALESCE function http://www.postgresql.org/docs/8.0/interactive/functions-conditional.html. Compare these SELECTs: CREATE TABLE test (num INTEGER); INSERT INTO test VALUES (1), (2), (null), (3), (null), (4), (0); SELECT num FROM test; SELECT COALESCE(num, 0) FROM test; but I think that integralism is somewhat wrong. Omar a programmer... ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Andrei Kovalevski PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PREPARE vs query with MULTIPLE statements
Yes, Thank you! Tom Lane wrote: Andrei Kovalevski <[EMAIL PROTECTED]> writes: 2) If I send it as 'PREPARE "SQL_CUR1" AS SELECT 1; SELECT 2; SELECT3; SELECT4;' and then 'EXECUTE "SQL_CUR1" - I'm getting: - results for SELECT 1; SELECT2; SELECT 3; - ReadyForQuery response - results for SELECT 4; - one more ReadyForQuery response from backend Is this behavour is correct and expected? You seem to have some odd ideas about what the semicolons mean. The prepare command there is PREPARE "SQL_CUR1" AS SELECT 1 ... no more and no less. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] PREPARE vs query with MULTIPLE statements
Hello. I have found an interesting FRONTEND/BACKEND protocol behaviour. Let's consider following query: "SELECT 1; SELECT 2; SELECT3; SELECT4;" 1) If I send it as a simple query - I'm getting: - correct results for SELECT 1; SELECT 2; SELECT3; SELECT4; - and then one ReadyForQuery response from backend. [send_simple.log & recv_simple.log] 2) If I send it as 'PREPARE "SQL_CUR1" AS SELECT 1; SELECT 2; SELECT3; SELECT4;' and then 'EXECUTE "SQL_CUR1" - I'm getting: - results for SELECT 1; SELECT2; SELECT 3; - ReadyForQuery response - results for SELECT 4; - one more ReadyForQuery response from backend [send_prepared.log & recv_prepared.log] Is this behavour is correct and expected? P.s. Tested on Windows with PostgreSQL 8.0, 8.1 and 8.2 with the same results. Thank You, Andrei. R #þTèR S client_encoding SQL_ASCII S DateStyle ISO, MDY S integer_datetimes off S is_superuser on S server_encoding SQL_ASCII S server_version 8.2.5 S !session_authorization andrei S $standard_conforming_strings off S TimeZone Europe/Helsinki K X`M¹Z IS client_encoding UNICODE C SET Z IT version ÿÿ D b XPostgreSQL 8.2.5 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special)C SELECT Z IC PREPARE T ! ?column? D 2C SELECT T ! ?column? D 3C SELECT T ! ?column? D 4C SELECT Z IT ! ?column? D 1C SELECT Z IR Ô²oÍR S client_encoding SQL_ASCII S DateStyle ISO, MDY S integer_datetimes off S is_superuser on S server_encoding SQL_ASCII S server_version 8.2.5 S !session_authorization andrei S $standard_conforming_strings off S TimeZone Europe/Helsinki K h]l»Z IS client_encoding UNICODE C SET Z IT version ÿÿ D b XPostgreSQL 8.2.5 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special)C SELECT Z IT ! ?column? D 1C SELECT T ! ?column? D 2C SELECT T ! ?column? D 3C SELECT T ! ?column? D 4C SELECT Z I # user andrei database test p (md5 Q %SET client_encoding to 'UNICODE' Q SELECT version() Q =PREPARE"SQL_CUR1"AS SELECT 1;SELECT 2;SELECT 3;SELECT 4; Q EXECUTE"SQL_CUR1"# user andrei database test p (md5 Q %SET client_encoding to 'UNICODE' Q SELECT version() Q )SELECT 1;SELECT 2;SELECT 3;SELECT 4; ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] .NET driver
Merlin Moncure wrote: On 8/2/07, Hannu Krosing <[EMAIL PROTECTED]> wrote: Ühel kenal päeval, N, 2007-08-02 kell 11:24, kirjutas Rohit Khare: I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET. As stated on NPGSQL page, it doesn't seem to provide seamless integration and performance with .NET. Instead when I used ODBC, the performance was comparatively better. What's the reason? When can we expect .NET driver that provides seamless integration. What kind of "seamless integration" are you looking for ? The .net data provider is not as good when working with typed datasets in terms of support from the ide. Normally for other providers the IDE does everything for you, writing update statements and such in a ORM fashion. This is kind of a pain for some of the report designers and other things that want to work with a typed set. It's possible to work around this, it's just a pain, and changes with each release of visual studio. Also, the connection pooling portions are buggy (google LOG: incomplete startup packet). The ODBC driver works pretty good actually. I can't speak about the performance though. merlin 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. Andrei. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] msvc and vista fun
Andrew Dunstan wrote: Dave Page wrote: Andrew Dunstan wrote: On a somewhat related note, I have had spectacular lack of success in getting either MSVC or MinGW builds to work on Vista - so much so that I have currently abandoned my attempts on that platform and I resorted to resuscitating an old XP box for testing. Following some advice from Magnus, I added ACLs to the build root for both an admin and a non-admin user (cacls buildroot /E /T /G AdminUser:C and similarly for a non-admin user) . I can build as the admin user but when I come to run initdb it fails, complaining that it can't find the postgres executable. Yeah, I ran into that problem as well. I'll look at my Vista box when I'm in the office tomorrow and see if I can figure out what hack fixed it for me. I have never heard back on this, AFAIK. If anyone has instructions on how to manage this please let me know. My current status with MSVC/vista is still that I can build but not run as an admin user, and run but not build as a non-admin user. Bleah. cheers andrew Described situation looks like you are trying to run initdb under Admin account. This will happen even if currently logged user in not admin, but initdb has property 'run as administrator' set or you are trying to run it under some file commander which is running in admin mode. Andrei. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Help! DLL make faild under windows mingw.
Hi! What exactly are you trying to build? If you have own-written Makefile for this - post it here. Does your code contain #define BUILDING_DLL before inclusion of PostgreSQL headers? Wang Haiyong wrote: > I am doing a DLL project, it is in the backend/utils/mb. But it can > not be maked under windows mingw. > I require everyone to help me. Thank your very much. > The error infomations are as follows. > Info: resolving _CurrentMemoryContext by linking to > __imp__CurrentMemoryContext (auto-import) > Info: resolving _SPI_processed by linking to __imp__SPI_processed > (auto-import) > Info: resolving _SPI_tuptable by linking to __imp__SPI_tuptable > (auto-import) > Info: resolving _default_statistics_target by linking to > __imp__default_statistics_target (auto-import) > fu01.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname' > fu02.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname' > fu03.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname' > fu04.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname' > fu05.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname' > fu06.o(.idata$3+0xc): more undefined references to > `libpostgres_a_iname' follow > nmth00.o(.idata$4+0x0): undefined reference to > `_nm__CurrentMemoryContext' > nmth000111.o(.idata$4+0x0): undefined reference to `_nm__SPI_processed' > nmth000118.o(.idata$4+0x0): undefined reference to `_nm__SPI_tuptable' > nmth000127.o(.idata$4+0x0): undefined reference to > `_nm__default_statistics_target' > d:\MinGW\bin\dllwrap.exe: d:\MinGW\bin\gcc exited with status 1 > make: *** [libnsqlgeom.dll] Error 1 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match