RE: [BUGS] create table bug with reserved words?
According to the documentation, CALL is in as a reserved word (7.1beta4 docs I think). The problem I have (and others may get) is porting apps from other databases that support reserved words as identifiers (SQL server being the main one). I assume the parser should know where it is (first and follow sets would define whether a reserved word is allowed or not?), so is there any reason why an identifier cannot cope with reserved words?. If not, can anyone point me in the direction of the code that does the parsing so I can take a look - if this would be helpful! Thanks, Chris -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 15 February 2001 15:23 To: Chris Storah Cc: [EMAIL PROTECTED] Subject: Re: [BUGS] create table bug with reserved words? Chris Storah <[EMAIL PROTECTED]> writes: > Is this a bug - should the parser cope with any reserved words as > identifiers? No, and no. If you could use them as identifiers then they wouldn't be reserved words, would they? Some keywords are "more reserved" than others in the Postgres parser; see the distinction between ColId and ColLabel in gram.y if you want the details. AFAICT, "CALL" is not a keyword at all in Postgres. regards, tom lane
[BUGS] Rules for Inserting Serials
I'm running the 7.1Beta4 (rpm binary) version on Mandrake 7.1. Rules that insert serials from the new object into another table don't give the same value as those inserted in the actual table. This looks to have been covered b4 here: http://www.postgresql.org/mhonarc/pgsql-bugs/2000-04/msg00060.html If this is indeed to remain the case I think it should be clearly documented in the rules section (I guess it would affect all defaults that use functions). Any way heres my script and stuff: <> <> - Stuart tbl_ins_test.sct ins_rule_test.sql
Re: [BUGS] create table bug with reserved words?
Chris Storah <[EMAIL PROTECTED]> writes: > If not, can anyone point me in the direction of the code that does the > parsing so I can take a look - if this would be helpful! src/backend/parser/gram.y. If you find that anything more can be moved out of the truly-reserved or ColLabel categories and added to the ColId category, let us know! But I think everything that's in ColLabel is there because you get parsing conflicts otherwise ... regards, tom lane
RE: [BUGS] create table bug with reserved words?
Chris Storah writes: > According to the documentation, CALL is in as a reserved word (7.1beta4 docs > I think). According to the documentation at http://www.postgresql.org/devel-corner/docs/postgres/sql-keywords-appendix.htm, CALL is not a key word (reserved or other) in PostgreSQL. That listing tends to be accurate, because it is generated straight from the code. > The problem I have (and others may get) is porting apps from other databases > that support reserved words as identifiers (SQL server being the main one). > > I assume the parser should know where it is (first and follow sets would > define whether a reserved word is allowed or not?), so is there any reason > why an identifier cannot cope with reserved words?. Unfortunately, the parser is a bit more complex than what can be put in a few words like "knows where it is". When you pick a particular parser model then you accept the technical limitations of that model. So when bison/yacc says, "The way you have written your grammar I cannot process it" then you have to change your grammar. One alternative is to unroll clauses, which is bug prone, creates maintenance problems, and bloats the program. The other alternative is to restrict the use of certain key words. While restricting any and every word when you're too bored to work harder to fix the parser is generally to be avoided, it is all the more acceptable if SQL actually says that the word should be reserved in conforming implementations. > If not, can anyone point me in the direction of the code that does the > parsing so I can take a look - if this would be helpful! src/backend/parser/gram.y But since the problematic word in your case is not CALL but SELECT, I can tell you right away with relative certainty that it will not be possible to change the parser to accept SELECT as an identifier in all contexts without butchering the grammar beyond reason. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [BUGS] create table bug with reserved words?
Peter Eisentraut <[EMAIL PROTECTED]> writes: > But since the problematic word in your case is not CALL but SELECT, I can > tell you right away with relative certainty that it will not be possible > to change the parser to accept SELECT as an identifier in all contexts > without butchering the grammar beyond reason. You can drop the "without" qualifier ;-) --- it's not possible period. Counterexample: SELECT (SELECT (3)) FROM foo; Is the second SELECT a (rather vacuous) sub-select, or is it a call of a function named SELECT? If you've got a really strong urge to use some keyword as an identifier, that's what double quotes are for. But the SQL syntax does require a lot of keywords to be reserved. I believe that we are actually more permissive in this respect than the SQL spec expects us to be. regards, tom lane
RE: [BUGS] create table bug with reserved words?
Peter Eisentraut wrote: >But since the problematic word in your case is not CALL but SELECT, I can >tell you right away with relative certainty that it will not be possible >to change the parser to accept SELECT as an identifier in all contexts >without butchering the grammar beyond reason. Just found out how MSSQL does it...it cheats! The parser takes 'create table test (select int)' and converts it into 'create table test ([select] int)'. I guess that this isn't an SQL92/99 compliant method :) Thanks for the help, Chris
[BUGS] NOTICE: pg_setlocale()
fmatheus ([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description NOTICE: pg_setlocale() Long Description Im a Debian user of postgresql version 7.0.3-4. libc6 and locales 2.2-6. (LANG=pt_BR, but problem stay with en_US) that is a unstable package so maybe that is fault of libc6. Sample Code SELECT to_char(2.4, 'L9990D99'); NOTICE: pg_setlocale(): 'LC_CTYPE= @x' cannot be honored. NOTICE: pg_setlocale(): 'LC_COLLATE=ð~µ' cannot be honored.. NOTICE: pg_setlocale(): 'LC_MONETARY=xµ@-^ù¸' cannot be honored.d. to_char R$2,40 No file was uploaded with this report
[BUGS] Bug #194 and #195 missing version
Sorry... forgot to add version. For bug #194 and #195 in the BugTool the version is: PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc 2.7.2.3 --d
[BUGS] On NetBSD, had to add -Wl,-R/usr/local/postgres/lib to the src/Makefile.global LIB variable
Priority: probably low. Background: uname -a: NetBSD scotts 1.5 NetBSD 1.5 (GENERIC) #1: Sun Nov 19 21:42:11 MET 2000 fvdl@sushi:/work/trees/netbsd-1-5/sys/arch/i386/compile/GENERIC i386 Postgresql version: 7.0.3 To configure I did a `./configure --prefix=/usr/local/postgres'. This is straight "out-of-the-box", so I didn't apply any of the NetBSD pkgsrc patches. My problem & fix: I had to add -Wl,-R/usr/local/postgres/lib to the src/Makefile.global LIB variable. Otherwise, doing a 'ldd /usr/local/postgres/bin/psql' after installation reported that it couldn't find libpg (`-lpq.2 => Not Found' or something like that). Remarks: There's almost certainly a better way, since src/Makefile.global is automatically generated, but I'm still getting acclimated to NetBSD and Postgres build. - Scott Williams
[BUGS] Regresstion Tests do not find PGLIB directory
-BEGIN PGP SIGNED MESSAGE- The output of a src/test/regress/'make runtest' command puts out: bash-2.04$ make runtest MULTIBYTE=;export MULTIBYTE; \ /bin/sh ./regress.sh i586-pc-linux-gnu 2>&1 | tee regress.out === Notes... = postmaster must already be running for the regression tests to succeed. The time zone is set to PST8PDT for these tests by the client frontend. Please report any apparent problems to [EMAIL PROTECTED] See regress/README for more information. === dropping old regression database... = DROP DATABASE === creating new regression database... = CREATE DATABASE === installing languages... = installing PL/pgSQL .. createlang: missing required argument PGLIB directory (This is the directory where the interpreter for the procedural language is stored. Traditionally, these are installed in whatever 'lib' directory was specified at configure time.) failed ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out To run the optional big test(s) too, type 'make bigtest' These big tests can take over an hour to complete These actually are: numeric_big I have configured and made postgresql according to its INSTALL instructions on a RedHat 7 pc system. I have added the appropriate line in /etc/ld.so.conf as suggested pointing to the lib directory under the postgresql installation. Such directory does exist and contains: bash-2.04$ ls -al /export/home/postgres/postgresql-7.0.3/lib total 1120 drwxrwxr-x2 postgres postgres 4096 Feb 15 11:42 . drwxr-xr-x 10 postgres postgres 4096 Feb 15 11:54 .. - - -r--r--r--1 postgres postgres 628 Feb 15 11:40 global1.bki.source - - -r--r--r--1 postgres postgres0 Feb 15 11:40 global1.description - - -rw-r--r--1 postgres postgres37350 Feb 15 11:40 libecpg.a lrwxrwxrwx1 postgres postgres 16 Feb 15 11:40 libecpg.so -> libecpg.so.3.1.1 lrwxrwxrwx1 postgres postgres 16 Feb 15 11:40 libecpg.so.3 -> libecpg.so.3.1.1 - - -rw-r--r--1 postgres postgres29584 Feb 15 11:40 libecpg.so.3.1.1 - - -rw-r--r--1 postgres postgres 6548 Feb 15 11:40 libpgeasy.a lrwxrwxrwx1 postgres postgres 16 Feb 15 11:40 libpgeasy.so -> libpgeasy.so.2.1 lrwxrwxrwx1 postgres postgres 16 Feb 15 11:40 libpgeasy.so.2 - - -> libpgeasy.so.2.1 - - -rw-r--r--1 postgres postgres 7971 Feb 15 11:40 libpgeasy.so.2.1 - - -rw-r--r--1 postgres postgres 370626 Feb 15 11:40 libpq++.a lrwxrwxrwx1 postgres postgres 14 Feb 15 11:40 libpq++.so -> libpq++.so.3.1 lrwxrwxrwx1 postgres postgres 14 Feb 15 11:40 libpq++.so.3 -> libpq++.so.3.1 - - -rw-r--r--1 postgres postgres 197278 Feb 15 11:40 libpq++.so.3.1 - - -rw-r--r--1 postgres postgres66378 Feb 15 11:40 libpq.a lrwxrwxrwx1 postgres postgres 12 Feb 15 11:40 libpq.so -> libpq.so.2.1 lrwxrwxrwx1 postgres postgres 12 Feb 15 11:40 libpq.so.2 -> libpq.so.2.1 - - -rw-r--r--1 postgres postgres59319 Feb 15 11:40 libpq.so.2.1 - - -r--r--r--1 postgres postgres 183974 Feb 15 11:40 local1_template1.bki.source - - -r--r--r--1 postgres postgres24692 Feb 15 11:40 local1_template1.description - - -r--r--r--1 postgres postgres 3407 Feb 15 11:40 pg_geqo.sample - - -r--r--r--1 postgres postgres 5729 Feb 15 11:40 pg_hba.conf.sample - - -r--r--r--1 postgres postgres 882 Feb 15 11:40 pg_ident.conf.sample - - -r--r--r--1 postgres postgres 7643 Feb 15 11:40 pg_options.sample - - -rw-r--r--1 postgres postgres72567 Feb 15 11:42 plpgsql.so - - -r--r--r--1 postgres postgres1 Feb 15 11:42 postmaster.opts.default.sample I have configured postgress with and without a --libdir definition and the get the same result on the regression testing attempts. The src/test/regress/run_check.sh sets PGLIB="$LIBDIR" but I have not been able to figure out how $LIBDIR should have been set, whereas now it seems not to be set. I have not been able to find any reference to PGLIB in the postgresql documentation. Any assistance would greatly be appreciated. Emily. Software Design Associates, Inc. -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBOow8G7qabQcdIDyxAQHeOQP5AbmkXVkj9mRHZ8tkdKBQvJtRUJzZ0DDz Vo7IeZ2Avh0VjPaPBomsuYbnsMjMNikavx3j4Xi7nL8020JFdA83sOE/R2Xq2SPw D4d+k00Di0ku8Mm6taS/50OB/AFC/oFxfh7XsVTGNvzPhbs76903TF2YnGC8Vkgi couGMnR98wE= =21R2 -END PGP SIGNATURE-
Re: [BUGS] On NetBSD, had to add -Wl,-R/usr/local/postgres/lib tothe src/Makefile.global LIB variable
Scott Williams writes: > I had to add -Wl,-R/usr/local/postgres/lib to the > src/Makefile.global LIB variable. Otherwise, doing a > 'ldd /usr/local/postgres/bin/psql' after installation > reported that it couldn't find libpg (`-lpq.2 => Not Found' > or something like that). In the past we have suggested to set the LD_LIBRARY_PATH variable appropriately. Version 7.1 fixes this by using the option you mention. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[BUGS] Re: Regresstion Tests do not find PGLIB directory
> I have configured and made postgresql according to its INSTALL > instructions on a RedHat 7 pc system. > I have added the appropriate line in /etc/ld.so.conf as suggested > pointing to the lib directory under the postgresql installation. You need to run ldconfig to actually update the shared library database. Or reboot, since usually ldconfig is run at boot time. Did the instructions mention /etc/ld.so.conf but not ldconfig? Perhaps you can suggest where in the docs we can make it clearer, or better yet, perhaps you can send patches for the doc/src/sgml/*.sgml files. - Thomas
Re: [BUGS] Regresstion Tests do not find PGLIB directory
Emily Carl writes: > The output of a src/test/regress/'make runtest' command puts out: > installing PL/pgSQL .. createlang: missing required argument PGLIB > directory > (This is the directory where the interpreter for the procedural > language is stored. Traditionally, these are installed in whatever > 'lib' directory was specified at configure time.) > failed > ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out > The src/test/regress/run_check.sh sets PGLIB="$LIBDIR" but I have not > been able to figure out how $LIBDIR should have been set, whereas now > it seems not to be set. I have not been able to find any reference to > PGLIB > in the postgresql documentation. LIBDIR should be in src/Makefile.global. What does it say there? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
