Обсуждение: PSQL anc compile errors
Hi, I refer to previous questions/answers with regards to psql not displaying the prompt correctly (ie, as => and NOT =#) and the up/down arrows not working: This is recorded in the documentation, which I have tried to follow, but still without luck. I have redhat 7.1 and postgres 7.1.3 I do have libreadline.a, readline.h and history.h in "appropriate" directories, but even if I do an explicit --with includes and --with-libs compile, I still do not get a psql which displays the prompt correctly. I have tried another hack mentioned by another entry in the list by using psql from a redhat 6.2 setup, but then I get the following error: psql: error while loading shared libraries: libpq.so.2.0: cannot load shared object file: No such file or directory Any more help please? (Even just a pointer to what entries I have to check when doing ./configure) ?? Thanks Tielman J de Villiers BondNet Pty Ltd
Tielman J de Villiers <tjdevil@bondnet.co.za> writes:
> I refer to previous questions/answers with regards to psql not displaying
> the prompt correctly (ie, as => and NOT =#) and the up/down arrows not
> working:
The prompt is not related to libreadline. It's set by psql itself based
on whether psql thinks you are logged in as a superuser. If psql is
getting the wrong answer on that, I'd be interested to see details of
your pg_user entries --- but don't blame libreadline.
On the other hand, if the up arrow doesn't bring back history, that
definitely suggests missing or broken libreadline support. You should
check whether the shared library loader is loading the right version of
libreadline. (I'm not on a Linux box right now, but IIRC there's some
configuration file in /etc that controls its search path, and you have
to update the cached search results after changing the config, too...
Our installation instructions cover this, I think.)
regards, tom lane
On Thu, 8 Nov 2001, Tom Lane wrote: > Tielman J de Villiers <tjdevil@bondnet.co.za> writes: > > I refer to previous questions/answers with regards to psql not displaying > > the prompt correctly (ie, as => and NOT =#) and the up/down arrows not > > working: > On the other hand, if the up arrow doesn't bring back history, that > definitely suggests missing or broken libreadline support. You should > check whether the shared library loader is loading the right version of > libreadline. Try ldd(1) over the psql executable. If libreadline doesn't show up, it isn't compiled to support it. If it was compiled with libreadline support, it wouldn't even load if it couldn't find it at runtime. > (I'm not on a Linux box right now, but IIRC there's some > configuration file in /etc that controls its search path, and you have > to update the cached search results after changing the config, too... > Our installation instructions cover this, I think.) That'd be /etc/ld.so.conf, and you can reload cached results by means of ldconfig(8). -- Alvaro Herrera (<alvherre[@]atentus.com>) "La gente vulgar solo piensa en pasar el tiempo; el que tiene talento, en aprovecharlo"
Thanks for the advice
An intermediate hack have solved my problem.
By using the old psql (compiled on redhat 6.2 and postgres 6.1)
And adding these links in /usr/lib:
libncurses.so.4 -> libncurses.so.5.2
libhistory.so.3 -> libhistory.so.4.1
libreadline.so.3 -> libreadline.so.4.1
And this in /usr/local/pgsql/lib:
libpq.so.2.0 -> libpq.so.2.1
Both the psql prompt and the up/down arrow (for history) are working
perfectly.
Tielman J de Villiers
BondNet Pty Ltd
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, November 08, 2001 6:29 PM
To: Tielman J de Villiers
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] PSQL anc compile errors
Tielman J de Villiers <tjdevil@bondnet.co.za> writes:
> I refer to previous questions/answers with regards to psql not
> displaying the prompt correctly (ie, as => and NOT =#) and the up/down
> arrows not
> working:
The prompt is not related to libreadline. It's set by psql itself based on
whether psql thinks you are logged in as a superuser. If psql is getting
the wrong answer on that, I'd be interested to see details of your pg_user
entries --- but don't blame libreadline.
On the other hand, if the up arrow doesn't bring back history, that
definitely suggests missing or broken libreadline support. You should check
whether the shared library loader is loading the right version of
libreadline. (I'm not on a Linux box right now, but IIRC there's some
configuration file in /etc that controls its search path, and you have to
update the cached search results after changing the config, too... Our
installation instructions cover this, I think.)
regards, tom lane
Thank you,
I did the following:
[root@dev postgresql-7.1.3]# ldconfig -v | grep 'readline'
libreadline.so.4.1 -> libreadline.so.4.1
[root@dev postgresql-7.1.3]# ldconfig -v | grep 'history'
libhistory.so.4.1 -> libhistory.so.4.1
Which, I think, means these two libraries are in the correct path when
compiling psql.
Then, if I go ldd /usr/local/pgsql/bin/psql:
libpq.so.2 => /usr/local/pgsql/lib/libpq.so.2 (0x40018000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40029000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40057000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4006a000)
libdl.so.2 => /lib/libdl.so.2 (0x40081000)
libm.so.6 => /lib/i686/libm.so.6 (0x40085000)
libhistory.so.4.1 => /usr/lib/libhistory.so.4.1 (0x400a9000)
libc.so.6 => /lib/i686/libc.so.6 (0x400b0000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Versus ldd /usr/local/pgsql/bin/psql.6.5.3 (the "old" one, which worked):
libpq.so.2.0 => /usr/local/pgsql/lib/libpq.so.2.0 (0x40018000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40029000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40057000)
libdl.so.2 => /lib/libdl.so.2 (0x4006e000)
libm.so.6 => /lib/i686/libm.so.6 (0x40072000)
libreadline.so.3 => /usr/lib/libreadline.so.3 (0x40096000)
libhistory.so.3 => /usr/lib/libhistory.so.3 (0x400bc000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x400c3000)
libncurses.so.4 => /usr/lib/libncurses.so.4 (0x400c7000)
libc.so.6 => /lib/i686/libc.so.6 (0x40109000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40239000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Which would mean the new psql was NOT compiled to support readline, as you
correctly suggested.
Any more suggestions, or do I just use the "old" psql?
Tielman J de Villiers
BondNet Pty Ltd
-----Original Message-----
From: Alvaro Herrera [mailto:alvherre@atentus.com]
Sent: Thursday, November 08, 2001 9:14 PM
To: Tom Lane
Cc: Tielman J de Villiers; pgsql-general@postgresql.org
Subject: Re: [GENERAL] PSQL anc compile errors
On Thu, 8 Nov 2001, Tom Lane wrote:
> Tielman J de Villiers <tjdevil@bondnet.co.za> writes:
> > I refer to previous questions/answers with regards to psql not
> > displaying the prompt correctly (ie, as => and NOT =#) and the
> > up/down arrows not
> > working:
> On the other hand, if the up arrow doesn't bring back history, that
> definitely suggests missing or broken libreadline support. You should
> check whether the shared library loader is loading the right version
> of libreadline.
Try ldd(1) over the psql executable. If libreadline doesn't show up, it
isn't compiled to support it. If it was compiled with libreadline support,
it wouldn't even load if it couldn't find it at runtime.
> (I'm not on a Linux box right now, but IIRC there's some configuration
> file in /etc that controls its search path, and you have to update the
> cached search results after changing the config, too... Our
> installation instructions cover this, I think.)
That'd be /etc/ld.so.conf, and you can reload cached results by means of
ldconfig(8).
--
Alvaro Herrera (<alvherre[@]atentus.com>)
"La gente vulgar solo piensa en pasar el tiempo;
el que tiene talento, en aprovecharlo"
I've got a view that combines a couple of tables. The view is meant to
simplify interactions with a Java application, so that selects, inserts,
and updates can be made on the view as if it were a real table. So, I
figured that rules would be the way to go. For inserts, I wrote a
do-instead rule for the view which in turn calls a function. The function
is meant to take the values from the insert statement and stick them into
the appropriate tables. However, functions appear to always return a value
(except as triggers), which confuses the JDBC. So, when I do an insert on
the view, the function is called and returns a value, causing the
following error:
A result was returned by the statement, when none was expected.
at org.postgresql.jdbc2.Statement.executeUpdate(Statement.java:80)
at
org.postgresql.jdbc2.PreparedStatement.executeUpdate(PreparedStatement.java:122)
I take it this is the expected JDBC behavior and not a bug. If so, what
are my options given that functions always return values and triggers
operate before or after inserts, but not instead of them? Is there some
way of calling functions so that they don't return a value? (If this
posting is more appropriate for another mailing list, please let me know.)
Thanks in advance.
-Stuart Robinson
Tielman J de Villiers <tjdevil@bondnet.co.za> writes:
> Which would mean the new psql was NOT compiled to support readline, as you
> correctly suggested.
That means the configure script failed to find the libreadline library
file, or include files, or both. You should rerun configure and pay
attention to the steps where it looks for readline-related stuff.
regards, tom lane