Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?
Bruce Momjian wrote: In any case please be consistent about the capitalization ... OK, updated text: --with-openssl build with OpenSSL support --with-libedit-preferred prefer Libedit over Libreadline --without-readline do not use Libreadline/Libedit line editing --without-zlib do not use Zlib They are called Readline and Libedit. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?
Peter Eisentraut wrote: Bruce Momjian wrote: In any case please be consistent about the capitalization ... OK, updated text: --with-openssl build with OpenSSL support --with-libedit-preferred prefer Libedit over Libreadline --without-readline do not use Libreadline/Libedit line editing --without-zlib do not use Zlib They are called Readline and Libedit. I wanted to distinguish libreadline from readline-functionality. Why is it Readline? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?
Bruce Momjian wrote: They are called Readline and Libedit. I wanted to distinguish libreadline from readline-functionality. The functionality may be called command-line editing but I don't see how that relates to what actually appears in the patch. Why is it Readline? PostgreSQL was already used. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?
Peter Eisentraut wrote: Bruce Momjian wrote: They are called Readline and Libedit. I wanted to distinguish libreadline from readline-functionality. The functionality may be called command-line editing but I don't see how that relates to what actually appears in the patch. When you use --without-readline, it really means without libreadline and libedit. One solution would be to rename that --without-lineediting, but that might confuse people. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?
Bruce Momjian wrote: I wanted to distinguish libreadline from readline-functionality. Why is it Readline? The GNU Readline Library is usually referred to as Readline, not libreadline. The offical name for libedit is really Libedit. See e.g.: http://sourceforge.net/projects/libedit/ http://cnswww.cns.cwru.edu/~chet/readline/rltop.html IMHO libreadline does not sound good. Best Regards, Michael Paesold ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?
Michael Paesold wrote:
Bruce Momjian wrote:
I wanted to distinguish libreadline from readline-functionality. Why is
it Readline?
The GNU Readline Library is usually referred to as Readline, not
libreadline. The offical name for libedit is really Libedit.
See e.g.:
http://sourceforge.net/projects/libedit/
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html
IMHO libreadline does not sound good.
OK, I call it GNU Readline now:
--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
--with-libedit-preferred prefer BSD Libedit over GNU Readline
--without-readline do not use GNU Readline / BSD Libedit line editing
--without-zlib do not use Zlib
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: configure
===
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.462
diff -c -c -r1.462 configure
*** configure 5 Nov 2005 16:42:00 - 1.462
--- configure 3 Dec 2005 15:25:44 -
***
*** 890,896
--with-pam build with PAM support
--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
! --without-readline do not use Readline
--without-zlib do not use Zlib
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
--- 890,897
--with-pam build with PAM support
--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
! --with-libedit-preferred prefer BSD Libedit over GNU Readline
! --without-readline do not use GNU Readline / BSD Libedit line editing
--without-zlib do not use Zlib
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
***
*** 3772,3777
--- 3773,3809
#
+ # Prefer libedit
+ #
+
+
+
+ # Check whether --with-libedit-preferred or --without-libedit-preferred was
given.
+ if test ${with_libedit_preferred+set} = set; then
+ withval=$with_libedit_preferred
+
+ case $withval in
+ yes)
+ :
+ ;;
+ no)
+ :
+ ;;
+ *)
+ { { echo $as_me:$LINENO: error: no argument expected for
--with-libedit-preferred option 5
+ echo $as_me: error: no argument expected for --with-libedit-preferred
option 2;}
+{ (exit 1); exit 1; }; }
+ ;;
+ esac
+
+ else
+ with_libedit_preferred=no
+
+ fi;
+
+
+
+ #
# Readline
#
***
*** 6490,6504
if test $with_readline = yes; then
- echo $as_me:$LINENO: checking for readline 5
- echo $ECHO_N checking for readline... $ECHO_C 6
if test ${pgac_cv_check_readline+set} = set; then
echo $ECHO_N (cached) $ECHO_C 6
else
pgac_cv_check_readline=no
pgac_save_LIBS=$LIBS
! for pgac_rllib in -lreadline -ledit ; do
for pgac_lib in -ltermcap -lncurses -lcurses ; do
LIBS=${pgac_rllib}${pgac_lib} $pgac_save_LIBS
cat conftest.$ac_ext _ACEOF
--- 6522,6540
if test $with_readline = yes; then
if test ${pgac_cv_check_readline+set} = set; then
echo $ECHO_N (cached) $ECHO_C 6
else
pgac_cv_check_readline=no
pgac_save_LIBS=$LIBS
! if test x$with_libedit_preferred != xyes
! then READLINE_ORDER=-lreadline -ledit
! else READLINE_ORDER=-ledit -lreadline
! fi
! for pgac_rllib in $READLINE_ORDER ; do
! echo $as_me:$LINENO: checking for ${pgac_rllib} 5
! echo $ECHO_N checking for ${pgac_rllib}... $ECHO_C 6
for pgac_lib in -ltermcap -lncurses -lcurses ; do
LIBS=${pgac_rllib}${pgac_lib} $pgac_save_LIBS
cat conftest.$ac_ext _ACEOF
***
*** 6557,6563
esac
pgac_cv_check_readline=${pgac_rllib}${pgac_lib}
! break 2
else
echo $as_me: failed program was: 5
--- 6593,6599
esac
pgac_cv_check_readline=${pgac_rllib}${pgac_lib}
! break
else
echo $as_me: failed program was: 5
***
*** 6567,6590
rm -f conftest.err conftest.$ac_objext \
conftest$ac_exeext conftest.$ac_ext
done
done
LIBS=$pgac_save_LIBS
fi
if test $pgac_cv_check_readline != no ; then
cat confdefs.h \_ACEOF
#define HAVE_LIBREADLINE 1
_ACEOF
- LIBS=$pgac_cv_check_readline $LIBS
- echo $as_me:$LINENO: result: yes ($pgac_cv_check_readline) 5
- echo ${ECHO_T}yes ($pgac_cv_check_readline) 6
- else
- echo $as_me:$LINENO: result: no 5
- echo ${ECHO_T}no 6
fi
if test x$pgac_cv_check_readline = xno; then
{ { echo $as_me:$LINENO: error: readline library not found
If you have readline already installed, see config.log for details on the
--- 6603,6631
rm -f conftest.err
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working under Windows
Nicolai Tufar wrote: Greetings, Last April we have made some changes to src/ports/snprintf.c so that it would support argument reordering like %2$s, %1$d and such on platforms where original snprintf() does not support it, like Windows, HP-UX or NetBSD. Sure, I remember. So glad you returned at this time. I found a design limitation in that file yesterday. It can not output more then 4096 characters, and there are some cases with NUMERIC that try to output more than that. For example: SELECT pow(10::numeric, 1) + 1; should show a '1' at the end of the number, but with the existing code you will just see 4095 0's and no more. I am attaching the new snprintf.c and the patch itself for your review. The change is to pass 'stream' down into the routines and output to the FILE* right from inside the routine, rather than using a string. This fixes the problem. I am also thinking of modifying the code so if we are using snprintf.c only because we need positional parameter control, we check for '$' in the string and only use snprintf.c in those cases. NLS messages of some languages, like Turkish, rely heavily on argument reordering because of the language structure. In 8.1 Turkish messages in Windows version are all broken because argument reordering is not there. Really? I have not heard any report of that but this is new code in 8.1. I examined commit logs and came to conclusion that src/port/snprintf.c is not included in server when compiling under Windows because of change to src/port/Makefile made in revision 1.28 by Bruce Momjian. See here: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/port/Makefile Comment to the commit says: `No server version of snprintf needed, so remove Makefile rule.' In fact I think we need snprintf in server because NLS messages are printed by the server. Actually, that changes means that there was nothing backend-specific in snprintf.c so we don't need a _special_ version for the backend. The real change not to use snprintf.c on Win32 is in configure.in with this comment: # Force use of our snprintf if system's doesn't do arg control # This feature is used by NLS if test $enable_nls = yes test $pgac_need_repl_snprintf = no # On Win32, libintl replaces snprintf() with its own version that # understands arg control, so we don't need our own. In fact, it # also uses macros that conflict with ours, so we _can't_ use # our own. test $PORTNAME != win32; then PGAC_FUNC_PRINTF_ARG_CONTROL if test $pgac_cv_printf_arg_control != yes ; then pgac_need_repl_snprintf=yes fi fi Here is the commit: revision 1.409 date: 2005/05/05 19:15:54; author: momjian; state: Exp; lines: +8 -2 On Win32, libintl replaces snprintf() with its own version that understands arg control, so we don't need our own. In fact, it also uses macros that conflict with ours, so we _can't_ use our own. So, I think it was Magnus who said that Win32 didn' need and couldn't use our snprintf. Magnus, any ideas? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 /* * Copyright (c) 1983, 1995, 1996 Eric P. Allman * Copyright (c) 1988, 1993 * The Regents of the University of California. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors *may be used to endorse or promote products derived from this software *without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL *
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working under Windows
Bruce Momjian pgman@candle.pha.pa.us writes: I am also thinking of modifying the code so if we are using snprintf.c only because we need positional parameter control, we check for '$' in the string and only use snprintf.c in those cases. What's the point? If the code is in there we may as well use it. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working under
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: I am also thinking of modifying the code so if we are using snprintf.c only because we need positional parameter control, we check for '$' in the string and only use snprintf.c in those cases. What's the point? If the code is in there we may as well use it. I was thinking it might avoid us hitting other bugs in there, but that is pessimistic, of course. I will hold off on that idea. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working under Windows in 8.1
Here is the commit: revision 1.409 date: 2005/05/05 19:15:54; author: momjian; state: Exp; lines: +8 -2 On Win32, libintl replaces snprintf() with its own version that understands arg control, so we don't need our own. In fact, it also uses macros that conflict with ours, so we _can't_ use our own. So, I think it was Magnus who said that Win32 didn' need and couldn't use our snprintf. Magnus, any ideas? I don't recall having said that. I can't promise I didn't, but if so I don't remember why. (And I do remember Nicolais fixes, so I think I should've thought of that before saying something like that) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Numeric 508 datatype
Bruce Momjian pgman@candle.pha.pa.us writes: (I could have done the struct but that seemed too invasive.) I think it'd be a lot cleaner with the struct. Mind if I take another pass at it? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] snprintf() argument reordering not working under Windows in 8.1
Greetings, I thought it will be as simple as changing Makefile, the issue seem to be much more complicated. Unfortunately I have no PostgreSQL building environment handy and will not be able to look at it until the end of next week because I am moving my house :( But since this issue waited for so long it may wait a week more. 2005/12/3, Bruce Momjian pgman@candle.pha.pa.us: Sure, I remember. So glad you returned at this time. I found a design limitation in that file yesterday. It can not output more then 4096 characters, and there are some cases with NUMERIC that try to output more than that. For example: SELECT pow(10::numeric, 1) + 1; should show a '1' at the end of the number, but with the existing code you will just see 4095 0's and no more. I am attaching the new snprintf.c and the patch itself for your review. The change is to pass 'stream' down into the routines and output to the FILE* right from inside the routine, rather than using a string. This fixes the problem. Your patch increase buffers from 4095 to 8192. Sounds good to me. I am also thinking of modifying the code so if we are using snprintf.c only because we need positional parameter control, we check for '$' in the string and only use snprintf.c in those cases. I too, was thinking of it at the beginning but decided that the code would get even more complicated than it was at the moment and was afraid that core team would not accept my patch. :) NLS messages of some languages, like Turkish, rely heavily on argument reordering because of the language structure. In 8.1 Turkish messages in Windows version are all broken because argument reordering is not there. Really? I have not heard any report of that but this is new code in 8.1. Windows installer does not set lc_messages configuration variable correctly in postgresql.conf file. It is a known issue and will be solved in next version. Meanwhile user needs to open postgresql.conf file and change lc_messages = 'Turkish_Turkey.28599' to lc_messages = 'tr_TR.UTF-8' manually. Apparently nobody cared to do it and Devrim never ever touches Windows. The problem is there, I am definitely positive about it, here are two lines from log file: 2005-11-20 12:36:37 HATA: $s yerinde $s 1 karakterinde 2005-12-03 19:14:27 LOG: $s veritabanın transaction ID warp limiti $u Actually, that changes means that there was nothing backend-specific in snprintf.c so we don't need a _special_ version for the backend. The real change not to use snprintf.c on Win32 is in configure.in with this comment: # Force use of our snprintf if system's doesn't do arg control # This feature is used by NLS if test $enable_nls = yes test $pgac_need_repl_snprintf = no # On Win32, libintl replaces snprintf() with its own version that # understands arg control, so we don't need our own. In fact, it # also uses macros that conflict with ours, so we _can't_ use # our own. test $PORTNAME != win32; then PGAC_FUNC_PRINTF_ARG_CONTROL if test $pgac_cv_printf_arg_control != yes ; then pgac_need_repl_snprintf=yes fi fi Here is the commit: revision 1.409 date: 2005/05/05 19:15:54; author: momjian; state: Exp; lines: +8 -2 On Win32, libintl replaces snprintf() with its own version that understands arg control, so we don't need our own. In fact, it also uses macros that conflict with ours, so we _can't_ use our own. I don't have MinGW build environment on my computer at the moment and will not be able to install it until the end of next week but log messages above were produced by PostgreSQL installed with 8.1.0-2 Windows installer downloaded from postgresql.org. Since Turkish messages are printed I suppose it was compiled with $enable_nls = yes Thank you for your attention, Regards, Nicolai Tufar ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Numeric 508 datatype
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: (I could have done the struct but that seemed too invasive.) I think it'd be a lot cleaner with the struct. Mind if I take another pass at it? OK, you want my patch or want me to apply and then you can modify? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] A couple of proposed pgbench changes
I have commited your fixes into PostgreSQL 8.1 stable branches.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Hi Tatsuo,
Attached is a proposed patch that deals with a couple of pgbench issues.
The change at line 490 updates doCustom's local variable commands
after selecting a new file (command sequence). I think that the
existing coding will cause the thing to use the first command of the
old sequence in the remainder of the routine, which would be a bug.
I have not tried to set up a test case to prove it, though.
The other two changes cause doCustom to loop after processing a
meta-command. This might be a bit controversial, but as the code
is currently written, each meta-command costs one cycle of the
outer select() loop. Thus, for example, with the default TPC-B script,
once a backend returns COMMIT it will not receive a new command
until four cycles of issuing commands to other backends have elapsed.
(You can see this very easily by strace'ing pgbench under load.)
ISTM it is bad to have backends sitting idle waiting for pgbench to
give them a new command. On the other hand you could argue that
finishing out several consecutive metacommands will delay issuance of
new commands to other backends. In the test case I was running,
making this change made for a small but noticeable improvement in
total CPU usage, but I'm not entirely convinced it'd always be a win.
I get the impression that pgbench itself is a bit of a bottleneck when
running on multi-CPU machines. I can't get the total CPU usage to reach
90% with ten client threads on a dual HT-enabled Xeon, and the only
explanation I can see is that there are too many backends waiting for
pgbench to give them new commands instead of doing useful work. strace
shows that each select() iteration usually finds *all ten* sockets
read-ready, which is definitely bad. (I tried nice'ing pgbench to
negative priority, but it did not improve matters. It could easily be
that this is a Heisenproblem, though, with strace itself slowing pgbench
enough to cause the behavior.) I wonder if it would help for pgbench to
fork off multiple sub-processes and have each sub-process tend just one
backend.
Anyway, since I'm not sure of either of these changes, I'm passing them
to you for review.
regards, tom lane
Index: pgbench.c
===
RCS file: /cvsroot/pgsql/contrib/pgbench/pgbench.c,v
retrieving revision 1.48
diff -c -r1.48 pgbench.c
*** pgbench.c 23 Nov 2005 12:19:12 - 1.48
--- pgbench.c 29 Nov 2005 23:51:46 -
***
*** 411,416
--- 411,417
CState *st = state[n];
Command **commands;
+ top:
commands = sql_files[st-use_file];
if (st-listen)
***
*** 489,494
--- 490,496
{
st-state = 0;
st-use_file = getrand(0, num_files - 1);
+ commands = sql_files[st-use_file];
}
}
***
*** 572,577
--- 574,581
free(val);
st-listen = 1;
}
+
+ goto top;
}
}
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] Numeric 508 datatype
Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: I think it'd be a lot cleaner with the struct. Mind if I take another pass at it? OK, you want my patch or want me to apply and then you can modify? You sent out your patch already --- I've been working from that. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Numeric 508 datatype
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: I think it'd be a lot cleaner with the struct. Mind if I take another pass at it? OK, you want my patch or want me to apply and then you can modify? You sent out your patch already --- I've been working from that. OK, thanks. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Should libedit be preferred to libreadline?
Patch applied.
---
Bruce Momjian wrote:
Michael Paesold wrote:
Bruce Momjian wrote:
I wanted to distinguish libreadline from readline-functionality. Why is
it Readline?
The GNU Readline Library is usually referred to as Readline, not
libreadline. The offical name for libedit is really Libedit.
See e.g.:
http://sourceforge.net/projects/libedit/
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html
IMHO libreadline does not sound good.
OK, I call it GNU Readline now:
--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
--with-libedit-preferred prefer BSD Libedit over GNU Readline
--without-readline do not use GNU Readline / BSD Libedit line editing
--without-zlib do not use Zlib
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: configure
===
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.462
diff -c -c -r1.462 configure
*** configure 5 Nov 2005 16:42:00 - 1.462
--- configure 3 Dec 2005 15:25:44 -
***
*** 890,896
--with-pam build with PAM support
--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
! --without-readline do not use Readline
--without-zlib do not use Zlib
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
--- 890,897
--with-pam build with PAM support
--with-bonjour build with Bonjour support
--with-openssl build with OpenSSL support
! --with-libedit-preferred prefer BSD Libedit over GNU Readline
! --without-readline do not use GNU Readline / BSD Libedit line editing
--without-zlib do not use Zlib
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
***
*** 3772,3777
--- 3773,3809
#
+ # Prefer libedit
+ #
+
+
+
+ # Check whether --with-libedit-preferred or --without-libedit-preferred was
given.
+ if test ${with_libedit_preferred+set} = set; then
+ withval=$with_libedit_preferred
+
+ case $withval in
+ yes)
+ :
+ ;;
+ no)
+ :
+ ;;
+ *)
+ { { echo $as_me:$LINENO: error: no argument expected for
--with-libedit-preferred option 5
+ echo $as_me: error: no argument expected for --with-libedit-preferred
option 2;}
+{ (exit 1); exit 1; }; }
+ ;;
+ esac
+
+ else
+ with_libedit_preferred=no
+
+ fi;
+
+
+
+ #
# Readline
#
***
*** 6490,6504
if test $with_readline = yes; then
- echo $as_me:$LINENO: checking for readline 5
- echo $ECHO_N checking for readline... $ECHO_C 6
if test ${pgac_cv_check_readline+set} = set; then
echo $ECHO_N (cached) $ECHO_C 6
else
pgac_cv_check_readline=no
pgac_save_LIBS=$LIBS
! for pgac_rllib in -lreadline -ledit ; do
for pgac_lib in -ltermcap -lncurses -lcurses ; do
LIBS=${pgac_rllib}${pgac_lib} $pgac_save_LIBS
cat conftest.$ac_ext _ACEOF
--- 6522,6540
if test $with_readline = yes; then
if test ${pgac_cv_check_readline+set} = set; then
echo $ECHO_N (cached) $ECHO_C 6
else
pgac_cv_check_readline=no
pgac_save_LIBS=$LIBS
! if test x$with_libedit_preferred != xyes
! thenREADLINE_ORDER=-lreadline -ledit
! elseREADLINE_ORDER=-ledit -lreadline
! fi
! for pgac_rllib in $READLINE_ORDER ; do
! echo $as_me:$LINENO: checking for ${pgac_rllib} 5
! echo $ECHO_N checking for ${pgac_rllib}... $ECHO_C 6
for pgac_lib in -ltermcap -lncurses -lcurses ; do
LIBS=${pgac_rllib}${pgac_lib} $pgac_save_LIBS
cat conftest.$ac_ext _ACEOF
***
*** 6557,6563
esac
pgac_cv_check_readline=${pgac_rllib}${pgac_lib}
! break 2
else
echo $as_me: failed program was: 5
--- 6593,6599
esac
pgac_cv_check_readline=${pgac_rllib}${pgac_lib}
! break
else
echo $as_me: failed program was: 5
***
*** 6567,6590
rm -f conftest.err conftest.$ac_objext \
conftest$ac_exeext conftest.$ac_ext
done
done
LIBS=$pgac_save_LIBS
fi
if test $pgac_cv_check_readline != no ; then
cat confdefs.h \_ACEOF
#define HAVE_LIBREADLINE 1
_ACEOF
- LIBS=$pgac_cv_check_readline $LIBS
- echo $as_me:$LINENO: result: yes ($pgac_cv_check_readline) 5
- echo ${ECHO_T}yes ($pgac_cv_check_readline) 6
- else
- echo
Re: [PATCHES] return can contains any row or record functions
Where are we on this patch? I don't see it as applied to CVS. --- Pavel Stehule wrote: - we can't use estate-rsi for the RETURN case, at least as presently implemented, because that is not always filled-out -- the example I gave before shows how because we don't check for a compatible TupleDesc when estate-rsi is NULL, we end up returning a value that is incompatible with the function's declared return type I expected so when rsi is NULL, then I haven't any info about desired record type, and then I have to skip checking for a compatibility (and I can it to do, because this is clean error, then is not necessery conversion, and next step do exception and error if returned type is wrong). I found different problem. It has maybe relation with Tom Lane's changes about returning one field records. And maybe wee need test for conversion everytime create or replace function a() returns record as $$ return (1); $$ language plpgsql; is syntax clean, it's row expression, but select a() ends with wrong result type supplied in RETURN. With change return (1,2), all works fine. return row(1) works well too. - therefore, we need to use some other way to get the TupleDesc of the function's declared return type. Offhand I think we can use estate-fn_rettype (plus the funcapi stuff for handling RECORDOID), but I haven't had a chance to try it yet. testing estate-fn_rettype is safer, but what is efectivity? Is necessery caching TupleDesc in retturn statement? I don't know? I don't study mechanism when is rsi valid or not. But I found some samples in source, when rsi was used for same purpose. Pavel _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
