Thread: No history in psql
Hello, I have installed PostgreSQL 7.1.3 from sources on SuSE Linux 7.3. The history of command line in psql doesn't work. I have used configure options --with-includes and --with-libraries. The required include files (readline.h history.h) and libraries (libreadline.a libhistory.a) are installed on my system. See below output from "configure" script: checking for readline... (cached) no checking for readline/readline.h... (cached) no checking for readline.h... (cached) no checking for readline/history.h... (cached) no What is wrong? Best Regards Jan Josefowicz
Jan Josefowicz <jj@system-j.de> writes:
> See below output from "configure" script:
> checking for readline... (cached) no
> checking for readline/readline.h... (cached) no
> checking for readline.h... (cached) no
> checking for readline/history.h... (cached) no
> What is wrong?
configure is reusing the results it got before. Remove the
"config.cache" file and try again.
regards, tom lane
Tom Lane wrote: > Jan Josefowicz <jj@system-j.de> writes: >> See below output from "configure" script: > >> checking for readline... (cached) no >> checking for readline/readline.h... (cached) no >> checking for readline.h... (cached) no >> checking for readline/history.h... (cached) no > >> What is wrong? > > configure is reusing the results it got before. Remove the > "config.cache" file and try again. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org Thank You, Tom the *.h and *.a files has been recognized, but I can not get the command line history in psql yet. Now I get following output from the configure script: checking for library containing using_history... none required. Is the problem outside of PostgreSQL? Regards, Jan Josefowicz
Jan <jj@system-j.de> writes:
> the *.h and *.a files has been recognized, but I can not get the command
> line history in psql yet. Now I get following output from the configure
> script:
> checking for library containing using_history... none required.
This is not a problem; I get the same thing.
Have you actually tried the resulting program to see if it works?
regards, tom lane
Tom Lane wrote: > Jan <jj@system-j.de> writes: >> the *.h and *.a files has been recognized, but I can not get the command >> line history in psql yet. Now I get following output from the configure >> script: >> checking for library containing using_history... none required. > > This is not a problem; I get the same thing. > > Have you actually tried the resulting program to see if it works? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org yes, of course. I have done following steps (many times): 1. close psql (\q) 2. stopping postmaster (Ctrl+c) 3. reinstalling PostgreSQL completely (rm config.cache, ./configure, make, make install(as root)) 4. I have checked the timestamps of the new created files in /usr/local/pgsql; they were correct. 5. starting postmaster 6. starting psql Regards, J.Josefowicz
Jan Josefowicz <jj@system-j.de> writes:
> Tom Lane wrote:
>> Jan <jj@system-j.de> writes:
> the *.h and *.a files has been recognized, but I can not get the command
> line history in psql yet. Now I get following output from the configure
> script:
> checking for library containing using_history... none required.
>>
>> This is not a problem; I get the same thing.
>>
>> Have you actually tried the resulting program to see if it works?
> yes, of course.
Hmm. Could we see the config.status and config.log files produced by
configure? Also, what version of libreadline are you using?
regards, tom lane
>> Tom Lane wrote: > > Hmm. Could we see the config.status and config.log files produced by > configure? Also, what version of libreadline are you using? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html Thanks for Your interest. Radline version is 4.2a. I think these files are too large for posting (a ca. 30K). May I email them? Regards, J. Josefowicz
Hi, I'm still not sure I've grasped what are (if any) the important differences between the classes PgDatabase and PgConnection -- some of the descriptions in the docs are identical for both classes, so I'm never sure when to use each (I kind of use PgDatabase by default, but maybe I'm missing something?) Also, I'm quite unsure about what should be the lifetime of the objects: should I create one database object when the application starts, and every time I need to execute an SQL statement, I call Exec? Or should I create a local database object whenever I need it? Normally, I would tend to think that one only object introduces minimum overhead... But then, I'm not sure if there are other factors to consider. My situation is more or less like this: I have a real-time system (not multi-threaded, though) which is the server in a multi-player online game. I'm going to use PostgreSQL for the database, which includes tables for the players (and their passwords and related data), and also for the games, chats, and plays. So, every time a player connects, I'll have to check the database of players to validate their logins (this might happen with a frequency of, say, a couple of times per second). When they're playing, everything will be added to the corresponding tables... This might happen with much higher frequency, I guess several hundred times per second, but the data to store in the database is not much (just a couple of bytes). What approach could you recommend concerning the two details mentioned in the subject? BTW, the above figures are (very rough) estimated peaks; of course, a sustained rate like that would fill up the hard disk in a couple of days :-) Thanks for any thoughts! Carlos --
Tom, many thanks for Your help. It works. Best Regards Jan Josefowicz
Jan Josefowicz <jj@system-j.de> writes:
> many thanks for Your help.
> It works.
For the record --- Jan's problem was that he was re-running configure
(after having installed libreadline), but he never did "make clean"
or "make distclean". So he still had the readline-free psql executable
he'd built to begin with.
I am right now adding something to the install instructions to warn
against this error.
regards, tom lane
On Sat, Jan 19, 2002 at 05:53:15PM -0500, Carlos Moreno wrote: > > I'm still not sure I've grasped what are (if any) the > important differences between the classes PgDatabase and > PgConnection -- some of the descriptions in the docs are > identical for both classes, so I'm never sure when to use > each (I kind of use PgDatabase by default, but maybe I'm > missing something?) The existing libpq++ is somewhat braindead when it comes to this. Basically, you use the simplest one that has all the methods you need--typically PgDatabase. I honestly have no idea why the two classes were separated in this way. What I usually tell people is to take a look at my alternative C++ frontend, libpqxx: http://members.ams.chello.nl/j.vermeulen31/proj-libpqxx.html And I intend to keep plugging this until it's included as the standard C++ API. :-) > Also, I'm quite unsure about what should be the lifetime > of the objects: should I create one database object when > the application starts, and every time I need to execute > an SQL statement, I call Exec? Or should I create a local > database object whenever I need it? In libpq++, you create your PgDatabase object and use that to do all your work. Or even better, make it a PgTransaction. Unfortunately this means you've got to open a new connection for every transaction. > What approach could you recommend concerning the two > details mentioned in the subject? With libpq++, create one PgDatabase object for the lifetime of your connection and build your own exception-safe wrapper to begin/abort/commit transactions. With libpqxx, create one Pg::Connection object for the lifetime of your connection and create Transactor classes for the transactions you need to do. Then, have your program invoke them in a robust, restartable manner using Connection::Perform(Transactor). Jeroen