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 wh
> 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 li
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 pas
-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... =
pos
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
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
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 unst
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
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 gram
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 listin
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
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.ht
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 f
13 matches
Mail list logo
