And to make things even better...

Steve Wolfe wrote:

/var/lib/pgsql reports that we're running 6.3 - which I don't find on the
FTP site. Is that not a valid distribution number, or is the source not
available?

Oh, I remember running 6.3. That was a looong time ago. Current version is
6.5.3 and 7.0 is about to be released. I would very much recommend an upgrade,
although you may want to wait for 7.0 to be released. I've been migrating
stuff accross to 7.0 RC1 (release candidate) and it is pretty solid and a vast
improvement on 6.3!

Adriaan

/var/lib/pgsql reports that we're running 6.3 - which I don't find on

the

FTP site. Is that not a valid distribution number, or is the source

not

available?

Oh, I remember running 6.3. That was a looong time ago. Current version

is

6.5.3 and 7.0 is about to be released. I would very much recommend an

upgrade,

although you may want to wait for 7.0 to be released. I've been migrating
stuff accross to 7.0 RC1 (release candidate) and it is pretty solid and a

vast

improvement on 6.3!

I'd also like to do an upgrade - however, I've never done an upgrade
before, there was a death in the family this morning, all of the
programmers are dead in the water until this is fixed, and we can't go to
the beta version just yet. So, I was hoping to have a fairly quick-fix for
this.

sigh.... what a day. : )

steve

Well, I bit the bullet and upgraded, and it was a fairly painless
procedure. Thanks again for the help...

steve

At 12:11 PM 19-04-2000 -0600, Steve Wolfe wrote:

/var/lib/pgsql reports that we're running 6.3 - which I don't find on the
FTP site. Is that not a valid distribution number, or is the source not
available?

Maybe the new guy did a make and linked the ancient 6.3 stuff in to Perl.

I suspect that you were in fact running 6.5.3. But now some stuff is going
to 6.3.

Check your postgres data directory, I believe you can find the version
number there.

Once you have confirmed the version you are really using, you can use the
correct binaries to back up/dump your data. Please check the docs on what
actually is dumped - certain things may not be dumped correctly depending
on which version you are using.

If you are daring you could "schedule" an upgrade to Postgresql 7.0. Hey
since it's already down and you have to recompile stuff <grin>. I'm kidding
of course, well half kidding.

Cheerio,

Link.

/var/lib/pgsql reports that we're running 6.3 - which I don't find on

the

FTP site. Is that not a valid distribution number, or is the source not
available?

Maybe the new guy did a make and linked the ancient 6.3 stuff in to Perl.

I suspect that you were in fact running 6.5.3. But now some stuff is

going

to 6.3.

Nope, it was bona-fide 6.3. : )

Check your postgres data directory, I believe you can find the version
number there.

That's where I found that. : )

Once you have confirmed the version you are really using, you can use the
correct binaries to back up/dump your data. Please check the docs on what
actually is dumped - certain things may not be dumped correctly depending
on which version you are using.

Part of the problem that I ran into was that the old guy had copied most
of the binaries from ~postgres/bin to other directories to get them in the
path. So, even after I wiped out the 6.3 directory and compiled 6.5.3,
when I'd do "initdb", it would create a 6.3 database structure, and make
everything barf. Fun, no?

steve

One last problem - after upgrading to 6.5.3, psql no longer seems to be
using the readline stuff for going through the command history, all we get
are the funky control characters ("^[[A^[[A", etc.) Any info on how to
make it work?

Oh, yes, it seems like 6.5.3 is more strict about not allowing you to use
reserved words for field names. Some nimrod had created a table with field
names 'time' and 'date', boy, did that make trying to restore fun, fun,
fun.....

steve

I've got the same problem with readline and psql using 7.0 RC1.

I found that there was something odd when ran configure. Here's the
readline stuff I grepped out of config.cache:

ac_cv_header_readline_h=${ac_cv_header_readline_h='no'}
ac_cv_header_readline_history_h=${ac_cv_header_readline_history_h='yes'}
ac_cv_header_readline_readline_h=${ac_cv_header_readline_readline_h='yes'}
ac_cv_lib_readline_main=${ac_cv_lib_readline_main='yes'}
ac_cv_lib_readline_using_history=${ac_cv_lib_readline_using_history='yes'}

Notice that the first line still says "no". Looks to me like it wants to
find readline.h in /usr/include, as well as, /usr/include/readline. Could
this be the source of the problem?

-=michael=-

*****************************************************
* Michael S. Kelly
* 4800 SW Griffith Dr., Ste. 202
* Beaverton, OR 97005 USA
* voice: (503)644-6106 x122 fax: (503)643-8425
* <michaelk@axian.com>
* http://www.axian.com/
*****************************************************
* Axian: Software Consulting and Training
*****************************************************

-----Original Message-----
From: Steve Wolfe [mailto:steve@iboats.com]
Sent: Thursday, April 20, 2000 9:51 AM
To: pgsql-general@postgresql.org
Subject: One last thing... psql and readline

One last problem - after upgrading to 6.5.3, psql no longer seems to be
using the readline stuff for going through the command history, all we get
are the funky control characters ("^[[A^[[A", etc.) Any info on how to
make it work?

Oh, yes, it seems like 6.5.3 is more strict about not allowing you to use
reserved words for field names. Some nimrod had created a table with field
names 'time' and 'date', boy, did that make trying to restore fun, fun,
fun.....

steve

I've got the same problem with readline and psql using 7.0 RC1.

I found that there was something odd when ran configure. Here's the
readline stuff I grepped out of config.cache:

ac_cv_header_readline_h=${ac_cv_header_readline_h='no'}

ac_cv_header_readline_history_h=${ac_cv_header_readline_history_h='yes'}

ac_cv_header_readline_readline_h=${ac_cv_header_readline_readline_h='yes'}

ac_cv_lib_readline_main=${ac_cv_lib_readline_main='yes'}

ac_cv_lib_readline_using_history=${ac_cv_lib_readline_using_history='yes'}

Notice that the first line still says "no". Looks to me like it wants to
find readline.h in /usr/include, as well as, /usr/include/readline.

Could

this be the source of the problem?

Interesting observation, thanks for following up. In my case, I gave up
(since the machine that needed the emergency upgrade was slightly
whacked-out), and copied the psql binary from a different machine, a Redhat
6.1 setup, where the readline stuff compiled succesfully. Sorry I can't be
of more help.... well, let me see...

On the system where it compiled succesfully, readline.h is only found in
/usr/include/readline/readline.h.

steve

I don't really follow how configure works (yet), however, I think this may be an
"OR" rather than an "AND". I believe (!) that different version of readline did
this differently and that is what is being checked for.

Mark

"Michael S. Kelly" wrote:

I've got the same problem with readline and psql using 7.0 RC1.

I found that there was something odd when ran configure. Here's the
readline stuff I grepped out of config.cache:

ac_cv_header_readline_h=${ac_cv_header_readline_h='no'}
ac_cv_header_readline_history_h=${ac_cv_header_readline_history_h='yes'}
ac_cv_header_readline_readline_h=${ac_cv_header_readline_readline_h='yes'}
ac_cv_lib_readline_main=${ac_cv_lib_readline_main='yes'}
ac_cv_lib_readline_using_history=${ac_cv_lib_readline_using_history='yes'}

Notice that the first line still says "no". Looks to me like it wants to
find readline.h in /usr/include, as well as, /usr/include/readline. Could
this be the source of the problem?

-=michael=-

*****************************************************
* Michael S. Kelly
* 4800 SW Griffith Dr., Ste. 202
* Beaverton, OR 97005 USA
* voice: (503)644-6106 x122 fax: (503)643-8425
* <michaelk@axian.com>
* http://www.axian.com/
*****************************************************
* Axian: Software Consulting and Training
*****************************************************

-----Original Message-----
From: Steve Wolfe [mailto:steve@iboats.com]
Sent: Thursday, April 20, 2000 9:51 AM
To: pgsql-general@postgresql.org
Subject: One last thing... psql and readline

One last problem - after upgrading to 6.5.3, psql no longer seems to be
using the readline stuff for going through the command history, all we get
are the funky control characters ("^[[A^[[A", etc.) Any info on how to
make it work?

Oh, yes, it seems like 6.5.3 is more strict about not allowing you to use
reserved words for field names. Some nimrod had created a table with field
names 'time' and 'date', boy, did that make trying to restore fun, fun,
fun.....

steve

--
Mark Dalphin email: mdalphin@amgen.com
Mail Stop: 29-2-A phone: +1-805-447-4951 (work)
One Amgen Center Drive +1-805-375-0680 (home)
Thousand Oaks, CA 91320 fax: +1-805-499-9955 (work)

Michael S. Kelly writes:

I've got the same problem with readline and psql using 7.0 RC1.

I found that there was something odd when ran configure. Here's the
readline stuff I grepped out of config.cache:

ac_cv_header_readline_h=${ac_cv_header_readline_h='no'}
ac_cv_header_readline_history_h=${ac_cv_header_readline_history_h='yes'}
ac_cv_header_readline_readline_h=${ac_cv_header_readline_readline_h='yes'}
ac_cv_lib_readline_main=${ac_cv_lib_readline_main='yes'}
ac_cv_lib_readline_using_history=${ac_cv_lib_readline_using_history='yes'}

Notice that the first line still says "no". Looks to me like it wants to
find readline.h in /usr/include, as well as, /usr/include/readline. Could
this be the source of the problem?

No, this is part of the solution. :) Across various versions of readline
the header files are either #include <readline.h> or #include
<readline/readline.h>, apparently for you the latter is the case.

I'm amazed that this won't enable readline support in psql. You can look
at src/include/config.h if the corresponding macros are defined
(HAVE_READLINE_READLINE_H and HAVE_LIBREADLINE). The other end of this is
src/bin/psql/input.[hc], perhaps you want to run the .c through the
preprocessor and see what happens. What readline version do you have? Did
it work in 6.5.*?

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden