Re: [BUGS] libpq in android
Excerpts from Marco Bernasocchi's message of mar nov 29 11:29:44 -0300 2011: > > Hi do you need an input from me? i used ifdef to be less invading to the > code. Please try what I suggest and see if it works on your platform. > On 11/25/2011 01:43 AM, Alvaro Herrera wrote: > > > > Excerpts from Peter Eisentraut's message of jue nov 24 19:01:04 -0300 2011: > >> On ons, 2011-11-23 at 12:07 +0100, Marco Bernasocchi wrote: > >>> Hi all, porting QGIS to android I ported libpq as well, I had to modify > >>> two files to successfully compile it without-readline. I attach the two > >>> needed minor patches. further informations can be found at > >>> android.qgis.org. > >> > >> The PostgreSQL source tree does not contain any file m4/libtool.m4. > >> > >> For the second patch, please try to find a feature-detection method of > >> addressing this problem (e.g., configure check), instead of > >> harding-coding #ifdef MYPLATFORM. > > > > FWIW I think this can be done simply by replacing the B64 struct member > > with int64. > > > -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq in android
Hi do you need an input from me? i used ifdef to be less invading to the code. On 11/25/2011 01:43 AM, Alvaro Herrera wrote: Excerpts from Peter Eisentraut's message of jue nov 24 19:01:04 -0300 2011: On ons, 2011-11-23 at 12:07 +0100, Marco Bernasocchi wrote: Hi all, porting QGIS to android I ported libpq as well, I had to modify two files to successfully compile it without-readline. I attach the two needed minor patches. further informations can be found at android.qgis.org. The PostgreSQL source tree does not contain any file m4/libtool.m4. For the second patch, please try to find a feature-detection method of addressing this problem (e.g., configure check), instead of harding-coding #ifdef MYPLATFORM. FWIW I think this can be done simply by replacing the B64 struct member with int64. -- Marco Bernasocchi www.opengis.ch -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6304: initdb fails with loale ko_KR.eucKR
Heikki, Thank you for your detailed analysis and response. I might play with the linker options - right now I am using the default "./configure ; make install" procedure and letting everything happen automatically. Another thought that I had was to wrap our use of "initdb" with a script that sets the LANG=C beforehand ... since we are using "--no-locale" option anyway it seems maybe unnecessary to honor the user's locale. Thanks again, Robert Balser -Original Message- From: Heikki Linnakangas [mailto:heikki.linnakan...@enterprisedb.com] Sent: Thursday, November 24, 2011 5:08 AM To: Balser, Robert W Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #6304: initdb fails with loale ko_KR.eucKR On 24.11.2011 12:23, Heikki Linnakangas wrote: > On 22.11.2011 23:18, Robert Balser wrote: >> >> The following bug has been logged online: >> >> Bug reference: 6304 >> Logged by: Robert Balser >> Email address: robert.bal...@hp.com >> PostgreSQL version: 9.0.5 >> Operating system: HPUX 11.31 ia64 >> Description: initdb fails with loale ko_KR.eucKR >> Details: >> >> If you set your LANG=ko_KR.eucKR to set your locale to Korean, the >> initdb command fails. It works with other locales, e.g. various >> Japanese, Chinese, and even other Korean locales (e.g. ko_KR.utf8). >> But ko_KR.eucKR always fails. The command being invoked is: >> >> initdb -E UTF8 --no-locale -D -U >> --pwfile= >> >> The output of initdb is an "sh:" error (in Korean), followed by a >> "fgets failure:" (also Korean), and then the following in English: >> >> The program "postgres" is needed by initdb but was not found in the >> same directory as "/bin/initdb". Check your installation. >> >> The postgres binary is of course in that folder, hence working with >> other locales. This doesn't look like a Postgres bug, I was able to reproduce this with the attached test program. It seems to depend heavily on the linker options used, this is the minimum set I was able to reduce it to. I think you'll have to pick it up from here with the HP compiler/ operating system guys.. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6067: In PL/pgsql, EXISTS(SELECT ... INTO...) fails
Tom Lane wrote: > "David Fetter" writes: > > IF EXISTS (SELECT 1 INTO STRICT i) THEN > > RAISE NOTICE '%', a; > > END IF; > > Umm ... are you just complaining that the error message isn't very > helpful, or are you actually expecting that to do something useful? > If the latter, what exactly? I'm particularly confused by your use > of the STRICT option here, because if we did support that, I would > expect the STRICT to throw an error if there were not exactly one > matching row, making the EXISTS test 100% pointless. > > But the short answer is that we don't support INTO in sub-selects, > and in general I doubt that we ever will, since in most cases the > behavior wouldn't be very well-defined. It might be worth a TODO > to provide a better error message than "syntax error", though. Is it worth documenting, fixing, or adding this to the TODO list? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6064: != NULL, <> NULL do not work [sec=UNCLASSIFIED]
Pilling, Michael wrote: > Hi Kevin, > > Thanks for that. Point entirely taken. I think what I would add would > be in the table 9-1 of operators, an extra column filled in only for > =, <> and != saying Important: see difference from IS [NOT] NULL. > Perhaps one reason I didn't pick up on this subtle issue is that IS > NULL and IS NOT NULL are not listed in this table but they are > comparison operators, just textual rather than symbolic ones in the > grammar so they should be in the table. I recall specifically looking > up what is the not equal operator in this language and only going > forward from the table, not realising I had to read any further. > > I'd also add after "Do not write expression = NULL because NULL is not > "equal to" NULL." Do not write expression != NULL or <> NULL because > NULL is not "not equal to" NULL. because while implied, it's not > obvious that because = doesn't work with NULL that != doesn't either. I have written the attached patch to mention <> NULL also returns NULL. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml new file mode 100644 index be92e6a..ddfb29a *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgml *** *** 364,371 Ordinary comparison operators yield null (signifying unknown), not true or false, when either input is null. For example, ! 7 = NULL yields null. When this behavior is not suitable, ! use the IS NOT DISTINCT FROM constructs: expression IS DISTINCT FROM expression --- 364,371 Ordinary comparison operators yield null (signifying unknown), not true or false, when either input is null. For example, ! 7 = NULL yields null, as does 7 <> NULL. When ! this behavior is not suitable, use the IS NOT DISTINCT FROM constructs: expression IS DISTINCT FROM expression -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
