Re: [PATCHES] [pgsql-hackers-win32] libpq build problem with io.h
Bruce, I posted the attached patch 4 days ago, with the comment The attached patch will redefine unlink and rename only if FRONTEND is not defined.. I still believe this a good way to fix it. Tom Lane wrote: To put that in a more positive light: we like to think that our code is Posix-compliant and runs in a Posix-compliant environment. We're not thrilled about introducing non-Posix-isms for the convenience of one platform ... especially if there's no easy way to enforce that the nonstandard coding convention be used. Back on track: if rename() does exist under Windows then my idea is unreliable. Any other thoughts? How about #including io.h in port.h (for Windows only of course) before we #define these things? Probably won't work, because pgrename and rename do not have the same definition/linkage. Regards, Andreas Index: port.h === RCS file: /projects/cvsroot/pgsql-server/src/include/port.h,v retrieving revision 1.52 diff -u -r1.52 port.h --- port.h 12 Aug 2004 18:32:43 - 1.52 +++ port.h 13 Aug 2004 15:58:19 - @@ -141,7 +141,7 @@ extern int pclose_check(FILE *stream); -#if defined(WIN32) || defined(__CYGWIN__) +#if (defined(WIN32) || defined(__CYGWIN__)) !defined(FRONTEND) /* * Win32 doesn't have reliable rename/unlink during concurrent access, * and we need special code to do symlinks. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [BUGS] BUG #1219: pgxs does not work fully
Please find enclose a submission to fix these problems. The patch adds missing the libpgport.a file to the installation under install-all-headers. It is needed by some contribs. I install the library in pkglibdir, but I was wondering whether it should be libdir? I was wondering also whether it would make sense to have a libpgport.so? It fixes various macros which are used by contrib makefiles, especially libpq_*dir and LDFLAGS when used under PGXS. It seems to me that they are needed to It adds the ability to test and use PGXS with contribs, with make USE_PGXS=1. Without the macro, this is exactly as before, there should be no difference, esp. wrt the vpath feature that seemed broken by previous submission. So it should not harm anybody, and it is useful at least to me. It fixes some inconsistencies in various contrib makefiles (useless override, := instead of =). It works for me. it validates. I'm available to fix any problem with this patch. Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED]*** ./contrib/btree_gist/Makefile.orig Fri May 28 15:09:43 2004 --- ./contrib/btree_gist/Makefile Tue Aug 17 11:54:08 2004 *** *** 1,8 - subdir = contrib/btree_gist - top_builddir = ../.. - include $(top_builddir)/src/Makefile.global - MODULE_big = btree_gist OBJS= btree_gist.o btree_utils_num.o btree_utils_var.o btree_int2.o btree_int4.o btree_int8.o \ --- 1,4 *** *** 16,19 --- 12,23 REGRESS = init int2 int4 int8 float4 float8 cash oid timestamp timestamptz time timetz \ date interval macaddr inet cidr text varchar char bytea bit varbit numeric + ifdef USE_PGXS + PGXS = $(shell pg_config --pgxs) + include $(PGXS) + else + subdir = contrib/btree_gist + top_builddir = ../.. + include $(top_builddir)/src/Makefile.global include $(top_srcdir)/contrib/contrib-global.mk + endif *** ./contrib/chkpass/Makefile.orig Sat Nov 29 20:51:19 2003 --- ./contrib/chkpass/Makefile Tue Aug 17 11:54:08 2004 *** *** 1,13 # $PostgreSQL: pgsql-server/contrib/chkpass/Makefile,v 1.5 2003/11/29 19:51:19 pgsql Exp $ - subdir = contrib/chkpass - top_builddir = ../.. - include $(top_builddir)/src/Makefile.global - MODULE_big = chkpass OBJS = chkpass.o SHLIB_LINK = $(filter -lcrypt, $(LIBS)) DATA_built = chkpass.sql DOCS = README.chkpass include $(top_srcdir)/contrib/contrib-global.mk --- 1,17 # $PostgreSQL: pgsql-server/contrib/chkpass/Makefile,v 1.5 2003/11/29 19:51:19 pgsql Exp $ MODULE_big = chkpass OBJS = chkpass.o SHLIB_LINK = $(filter -lcrypt, $(LIBS)) DATA_built = chkpass.sql DOCS = README.chkpass + ifdef USE_PGXS + PGXS = $(shell pg_config --pgxs) + include $(PGXS) + else + subdir = contrib/chkpass + top_builddir = ../.. + include $(top_builddir)/src/Makefile.global include $(top_srcdir)/contrib/contrib-global.mk + endif *** ./contrib/cube/Makefile.origSat Nov 29 20:51:21 2003 --- ./contrib/cube/Makefile Tue Aug 17 11:54:08 2004 *** *** 1,9 # $PostgreSQL: pgsql-server/contrib/cube/Makefile,v 1.11 2003/11/29 19:51:21 pgsql Exp $ - subdir = contrib/cube - top_builddir = ../.. - include $(top_builddir)/src/Makefile.global - MODULE_big = cube OBJS= cube.o cubeparse.o --- 1,5 *** *** 11,16 --- 7,25 DOCS = README.cube REGRESS = cube + EXTRA_CLEAN = cubeparse.c cubeparse.h cubescan.c y.tab.c y.tab.h + + + ifdef USE_PGXS + PGXS = $(shell pg_config --pgxs) + include $(PGXS) + else + subdir = contrib/cube + top_builddir = ../.. + include $(top_builddir)/src/Makefile.global + include $(top_srcdir)/contrib/contrib-global.mk + endif + # cubescan is compiled as part of cubeparse cubeparse.o: cubescan.c *** *** 32,39 else @$(missing) flex $ $@ endif - - EXTRA_CLEAN = cubeparse.c cubeparse.h cubescan.c y.tab.c y.tab.h - - - include $(top_srcdir)/contrib/contrib-global.mk --- 41,43 *** ./contrib/dbase/Makefile.orig Sat Nov 29 20:51:22 2003 --- ./contrib/dbase/MakefileTue Aug 17 11:54:08 2004 *** *** 1,9 # $PostgreSQL: pgsql-server/contrib/dbase/Makefile,v 1.5 2003/11/29 19:51:22 pgsql Exp $ - subdir = contrib/dbase - top_builddir = ../.. - include $(top_builddir)/src/Makefile.global - PROGRAM = dbf2pg OBJS = dbf.o dbf2pg.o endian.o PG_CPPFLAGS = -I$(libpq_srcdir) --- 1,5 *** *** 18,21 --- 14,26 DOCS = README.dbf2pg MAN = dbf2pg.1# XXX not implemented + + ifdef USE_PGXS + PGXS = $(shell pg_config --pgxs) + include $(PGXS) + else + subdir = contrib/dbase + top_builddir = ../.. + include $(top_builddir)/src/Makefile.global include $(top_srcdir)/contrib/contrib-global.mk + endif *** ./contrib/dblink/Makefile.orig Sat Nov 29 20:51:34 2003 --- ./contrib/dblink/Makefile Tue Aug 17 11:54:08 2004 *** *** 1,9 # $PostgreSQL:
Re: [PATCHES] [pgsql-hackers-win32] libpq build problem with io.h on MS VC++
Andreas Pflug [EMAIL PROTECTED] writes: Back on track: if rename() does exist under Windows then my idea is unreliable. Any other thoughts? How about #including io.h in port.h (for Windows only of course) before we #define these things? Probably won't work, because pgrename and rename do not have the same definition/linkage. So? The compiler would see something like extern linkage_spec rename(...); extern int pgrename(...); #define rename pgrename so the conflict of linkage spec shouldn't bother anything. I posted the attached patch 4 days ago, with the comment The attached patch will redefine unlink and rename only if FRONTEND is not defined.. I still believe this a good way to fix it. The conflict would still exist. AFAICS it's pure chance that it's not affecting any backend modules at the moment. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [pgsql-hackers-win32] libpq build problem with io.h on MS VC++
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Ah, one thing we have done is to reference everything as pg* and define it to be the libc function on unix and give a compatibility function on Win32. We do that with pgpipe. That might be our best solution. We should do that sort of thing only as a very last resort. It's particularly bad when we cannot easily enforce that all references use the pgxxx function. pgpipe is manageable because there are very few places that need to use it, but the same cannot be said of rename. Personally I'd rather get rid of pgpipe as well ... Yes, that is true that we can't know we hit all the places that need to use pg*. I added a comment in port.h: * There is some inconsistency here because sometimes we require pg*, like * pgpipe, but in other cases we define rename to pgrename just on Win32. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 8: explain analyze is your friend
Re: [PATCHES] [pgsql-hackers-win32] libpq build problem with io.h on MS VC++
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Andrew Francis wrote: How about avoiding #define altogether, and: - Always use pgrename/pgunlink instead of rename/unlink We could do it but we have avoided that for cases where Unix would just be a pass-through. To put that in a more positive light: we like to think that our code is Posix-compliant and runs in a Posix-compliant environment. We're not thrilled about introducing non-Posix-isms for the convenience of one platform ... especially if there's no easy way to enforce that the nonstandard coding convention be used. Back on track: if rename() does exist under Windows then my idea is unreliable. Any other thoughts? How about #including io.h in port.h (for Windows only of course) before we #define these things? Sure, should we do that? I see 12 mentions of io.h in the code, and we already include some win32 includes in port.h. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [pgsql-hackers-win32] GUC variables invisible to contrib/
I am not really sure what the official way of accessing guc variables is because we haven't had a lot of external apps using them in the past, and Win32 is a newer platform for us. --- Mark Cave-Ayland wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: 17 August 2004 03:51 To: Mark Cave-Ayland Cc: [EMAIL PROTECTED]; PostgreSQL-patches Subject: Re: [PATCHES] [pgsql-hackers-win32] GUC variables invisible to contrib/ modules Yep, DLLIMPORT is the right fix. Patch attached and applied. -- Hi Bruce, I had actually gone for Andreas' suggestion and included the DLLIMPORT in an extern declaration so thanks for applying the patch. However, I'm still not convinced that this is the best thing to do in this case. This is because we either allow access to all GUC variables (in which case we need to locate them all and mark them as DLLIMPORT) or otherwise provide another mechanism to get this information. Looking at Thomas' patch (http://archives.postgresql.org/pgsql-patches/2004-04/msg00280.php) it seems that using GetConfigOption() is the only way that will work without knowing the underlying variable name that stores your GUC value (this may not necessarily be the same name as the parameter in postgresql.conf) and also work with new custom GUC variables. So I guess I was looking more for clarification that this was the official way to access GUC information? (I see this also as being less likely to break in future, since if the underlying variable name changes, everything will still work unless the parameter changes its name) Many thanks, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [pgsql-hackers-win32] GUC variables invisible to contrib/ modules
Mark Cave-Ayland [EMAIL PROTECTED] writes: So I guess I was looking more for clarification that this was the official way to access GUC information? It isn't, and isn't likely to become so, at least not for C code. We generally think of the C code as being at a lower level than SQL. If we rename a global variable that underlies a GUC variable, it's probably because we *want* to break any C code that references it --- perhaps the semantics are changing, or something like that. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [BUGS] 8.0.0beta1: -lpthread missing
OK, I got it working now. Seems the code needed more help to loop than I though, and of course trying to change it as little as possible caused me to miss that. The attached, applied patch properly aggregates the thread flags. The bad news is that on my platform that needs _no_ thread flags or libraries I have: PTHREAD_CFLAGS = -Kthread -kthread -pthread -pthreads -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS PTHREAD_LIBS= I assume those are just ignored for portability so I assume we are OK. --- Martin Münstermann wrote: Bruce Momjian wrote: OK, I found the cause. I forgot to run autoconf after the config/acx_pthread.m4 updated. I just did so. Please retest. Thanks. Ok, I did an cvs update and rerun configure. Now it gives me an error: [...] checking whether pthreads work with -pthread... no checking whether pthreads work with -pthreads... yes checking for the pthreads library -lpthread... yes checking whether pthreads work with -mt... yes checking for the pthreads library -lpthreads... yes checking whether pthreads work without any flags... yes checking whether pthreads work with -Kthread... yes checking whether pthreads work with -kthread... yes checking for the pthreads library -llthread... yes checking whether pthreads work with -pthread... yes checking whether pthreads work with -pthreads... yes checking whether pthreads work with -mthreads... yes checking for the pthreads library -lpthread... yes checking whether pthreads work with --thread-safe... yes checking whether pthreads work with -mt... yes checking for joinable pthread attribute... unknown configure: WARNING: we do not know how to create joinable pthreads [Oooops.] checking if more special flags are required for pthreads... no checking for cc_r... gcc checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking for strerror_r... no checking for getpwuid_r... no checking for gethostbyname_r... no checking whether getpwuid_r takes a fifth argument... no checking whether strerror_r returns int... no [...] checking thread safety of required library functions... no configure: error: *** Thread test program failed. Your platform is not thread-safe. *** Check the file 'config.log'for the exact reason. *** *** You can use the configure option --enable-thread-safety-force *** to force threads to be enabled. However, you must then run *** the program in src/tools/thread and add locking function calls *** to your applications to guarantee thread safety. Bruce, I will send you my config.log privately. Regards, Martin -= -- Martin M=FCnstermann wrote: Bruce Momjian wrote: -- We need -lpthread on solaris, too. =20 =20 So the current CVS code is good? =20 No. At least not for solaris8. =20 configure says: checking whether pthreads work with -pthread... no checking whether pthreads work with -pthreads... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking for cc_r... gcc checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes =20 =20 Makefile.global: PTHREAD_CFLAGS =3D -pthreads -D_REENTRANT -D_THREAD_SAFE=20 -D_POSIX_PTHREAD_SEMANTICS PTHREAD_LIBS=3D =20 No -lpthread and the resulting binaries have no dependancy on=20 libpthread.so, so at runtime only the stubs are being called. =20 Regards, Martin =20 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] libpq problem
OK, I like your idea of chaining on to any existing SIGPIPE handler
rather than just do it if none is installed. I also see your fix for
the uninitialized thread-specific variable.
I added some comments to the patch, renamed the pipeheader variable so
it was pg_* to avoid namespace conflicts, and updated the documentation.
Patch attached and applied.
---
Andreas Pflug wrote:
Andreas Pflug wrote:
Some recent change in libpq seems to interfere with gtk.
After I tested a new pgadmin3 version on linuy yesterday, I found that
the GUI is hanging after PQconnectdb was called. After the call, the db
connection is fully functional, but the GUI mouse will show waiting
and the program doesn't react to mouse clicks any more; screen updates
are not performed either.
When I replace the 8.0 libpq.so* version with an older saved version
(7.4.3 from debian installation) it works ok.
OK, I found out. Seems I didn't run make distclean for a longer time, so
I didn't realize earlier.
The reason is the sigpipe handling code. If the app (in this case: some
gtk internals) already installed a SIGPIPE handler, the thread_in_send
key is not created. pthread_setspecific calls will thus use an invalid
key, which screws up gtk.
The attached patch will implement two features:
1) unconditionally create thread_in_send
2) Always register our own SIGPIPE handler, chain to a previously
registered handler when the signal is thrown while not sending.
Regards,
Andreas
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/libpq.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/libpq.sgml,v
retrieving revision 1.159
diff -c -c -r1.159 libpq.sgml
*** doc/src/sgml/libpq.sgml 16 Aug 2004 02:12:29 - 1.159
--- doc/src/sgml/libpq.sgml 17 Aug 2004 16:43:10 -
***
*** 3738,3745
functionsend()/ call and restores the original signal handler after
completion. When literal--enable-thread-safety/ is used,
applicationlibpq/ installs its own literalSIGPIPE/ handler
! before the first database connection if no custom literalSIGPIPE/
! handler has been installed previously. This handler uses thread-local
storage to determine if a literalSIGPIPE/ signal has been generated
by a libpq functionsend()/. If an application wants to install
its own literalSIGPIPE/ signal handler, it should call
--- 3738,3744
functionsend()/ call and restores the original signal handler after
completion. When literal--enable-thread-safety/ is used,
applicationlibpq/ installs its own literalSIGPIPE/ handler
! before the first database connection. This handler uses thread-local
storage to determine if a literalSIGPIPE/ signal has been generated
by a libpq functionsend()/. If an application wants to install
its own literalSIGPIPE/ signal handler, it should call
Index: src/interfaces/libpq/fe-secure.c
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.46
diff -c -c -r1.46 fe-secure.c
*** src/interfaces/libpq/fe-secure.c17 Aug 2004 04:24:23 - 1.46
--- src/interfaces/libpq/fe-secure.c17 Aug 2004 16:43:19 -
***
*** 152,158
#ifdef ENABLE_THREAD_SAFETY
static void sigpipe_handler_ignore_send(int signo);
! pthread_key_t pq_thread_in_send = 0;
#endif
/* */
--- 152,159
#ifdef ENABLE_THREAD_SAFETY
static void sigpipe_handler_ignore_send(int signo);
! pthread_key_t pq_thread_in_send = 0; /* initializer needed on Darwin */
! static pqsigfunc pq_pipe_handler;
#endif
/* */
***
*** 1190,1212
void
pq_check_sigpipe_handler(void)
{
! pqsigfunc pipehandler;
!
/*
!* If the app hasn't set a SIGPIPE handler, define our own
!* that ignores SIGPIPE on libpq send() and does SIG_DFL
!* for other SIGPIPE cases.
*/
! pipehandler = pqsignalinquire(SIGPIPE);
! if (pipehandler == SIG_DFL) /* not set by application */
! {
! /*
!* Create key first because the signal handler might be called
!* right after being installed.
!*/
!
Re: [PATCHES] Allow psql to work against non-tablespace servers (e.g.
I don't see any other code in psql that allows it to run with older
server versions so it doesn't make sense to me to fix things just for
tablespaces, and doing it for everything seems like it would uglify the
code too much.
---
Greg Sabino Mullane wrote:
Index: describe.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/describe.c,v
retrieving revision 1.103
diff -c -r1.103 describe.c
*** describe.c15 Jul 2004 03:56:06 - 1.103
--- describe.c11 Aug 2004 21:15:34 -
***
*** 112,117
--- 112,123
PGresult *res;
printQueryOpt myopt = pset.popt;
+ if (pset.sversion 70500) {
+ fprintf(stderr, _(This server version (%d) does not support
tablespaces.\n),
+ pset.sversion);
+ return true;
+ }
+
initPQExpBuffer(buf);
printfPQExpBuffer(buf,
***
*** 706,713
/* Get general table info */
printfPQExpBuffer(buf,
SELECT relhasindex, relkind, relchecks, reltriggers, relhasrules, \n
! relhasoids, reltablespace \n
FROM pg_catalog.pg_class WHERE oid = `%s`,
oid);
res = PSQLexec(buf.data, false);
if (!res)
--- 712,720
/* Get general table info */
printfPQExpBuffer(buf,
SELECT relhasindex, relkind, relchecks, reltriggers, relhasrules, \n
! relhasoids %s \n
FROM pg_catalog.pg_class WHERE oid = `%s`,
+
pset.sversion = 70500 ? , reltablespace : ,
oid);
res = PSQLexec(buf.data, false);
if (!res)
***
*** 729,735
tableinfo.hasindex = strcmp(PQgetvalue(res, 0, 0), t) == 0;
tableinfo.hasrules = strcmp(PQgetvalue(res, 0, 4), t) == 0;
tableinfo.hasoids = strcmp(PQgetvalue(res, 0, 5), t) == 0;
! tableinfo.tablespace = atooid(PQgetvalue(res, 0, 6));
PQclear(res);
headers[0] = _(Column);
--- 736,743
tableinfo.hasindex = strcmp(PQgetvalue(res, 0, 0), t) == 0;
tableinfo.hasrules = strcmp(PQgetvalue(res, 0, 4), t) == 0;
tableinfo.hasoids = strcmp(PQgetvalue(res, 0, 5), t) == 0;
! tableinfo.tablespace = (pset.sversion = 70500) ?
! atooid(PQgetvalue(res, 0, 6)) : 0;
PQclear(res);
headers[0] = _(Column);
***
*** 932,939
footers = pg_malloc_zero(4 * sizeof(*footers));
footers[count_footers++] = pg_strdup(tmpbuf.data);
! add_tablespace_footer(tableinfo.relkind, tableinfo.tablespace,
! footers, count_footers, tmpbuf);
footers[count_footers] = NULL;
}
--- 940,947
footers = pg_malloc_zero(4 * sizeof(*footers));
footers[count_footers++] = pg_strdup(tmpbuf.data);
! add_tablespace_footer(tableinfo.relkind, tableinfo.tablespace,
!
footers, count_footers, tmpbuf);
footers[count_footers] = NULL;
}
Index: settings.h
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/settings.h,v
retrieving revision 1.18
diff -c -r1.18 settings.h
*** settings.h12 May 2004 13:38:45 - 1.18
--- settings.h11 Aug 2004 21:15:34 -
***
*** 41,47
FILE *cur_cmd_source; /* describe the status of the current main
* loop */
boolcur_cmd_interactive;
!
const char *progname; /* in case you renamed psql */
char *inputfile; /* for error reporting */
unsignedlineno; /* also for error reporting */
--- 41,47
FILE *cur_cmd_source; /* describe the status of the current main
* loop */
boolcur_cmd_interactive;
! int sversion; /* backend server version */
const char *progname; /* in case you renamed psql */
char *inputfile; /* for error reporting */
unsignedlineno; /* also for error reporting */
Index: startup.c
Re: [PATCHES] [HACKERS] libpq problem
Bruce Momjian wrote: OK, I like your idea of chaining on to any existing SIGPIPE handler rather than just do it if none is installed. I also see your fix for the uninitialized thread-specific variable. I added some comments to the patch, renamed the pipeheader variable so it was pg_* to avoid namespace conflicts, and updated the documentation. Patch attached and applied. At a glance, this looks like it will break applications that pass SA_SIGINFO in sa_flags for their SIGPIPE handlers. This changes the expected signal handler signature to a three-arg form; the extra two args provide context about where the signal occurred. The libpq handler, however, doesn't pass those args when chaining to the next handler. The Sun JVM under linux is one example of an app that does1 this. I've seen a similar problem to this before with a version of libnss_ldap that did not correctly restore the entire sigaction state when restoring the SIGPIPE handler before returning from libnss_ldap .. the next SIGPIPE that arrives would crash the JVM. See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4630104 for more details (requires registration) -O ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Allow psql to work against non-tablespace servers (e.g.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't see any other code in psql that allows it to run with older server versions so it doesn't make sense to me to fix things just for tablespaces, and doing it for everything seems like it would uglify the code too much. Tablespace are the only main difference between 8.0 and 7.4 as far as psql is concerned, so the patch will allow psql to work against 7.4 servers seamlessly. If I get time, I will begin making psql backward-compatible to 7.3 and further, but the changes to do so will not be as small as this patch and I would rather they get evaluated separately. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200408172006 -BEGIN PGP SIGNATURE- iD8DBQFBIp3IvJuQZxSWSsgRAuABAJ0Yzhl7neFUsufTSBRPCw4FtgFHmwCfRF7C 3y+2SRPeIbt5ZAhmSQgHogc= =t52z -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Allow psql to work against non-tablespace servers (e.g.
Greg Sabino Mullane wrote: [ There is text before PGP section. ] [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't see any other code in psql that allows it to run with older server versions so it doesn't make sense to me to fix things just for tablespaces, and doing it for everything seems like it would uglify the code too much. Tablespace are the only main difference between 8.0 and 7.4 as far as psql is concerned, so the patch will allow psql to work against 7.4 servers seamlessly. If I get time, I will begin making psql backward-compatible to 7.3 and further, but the changes to do so will not be as small as this patch and I would rather they get evaluated separately. But do we want to do this? Is it worth doing, and maintaining? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 7: don't forget to increase your free space map settings
Re: [PATCHES] Allow psql to work against non-tablespace servers (e.g.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If I get time, I will begin making psql backward-compatible to 7.3 and further, but the changes to do so will not be as small as this patch and I would rather they get evaluated separately. But do we want to do this? Is it worth doing, and maintaining? I think so, within reason. Certainly going back to 7.4 is worthy, and probably 7.3 as well. Going back to 7.2 is probably not: in addition to major changes due to schemas appearing, it is a pretty old version at this point. People have certainly expressed interest in the past as far making psql backwards-compatible, and I think the code can be kept fairly clean. At least we are guaranteed to compile against current libraries - apps outside the source tree never get that luxury and have worse compatibility problems. :) - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200408172031 -BEGIN PGP SIGNATURE- iD8DBQFBIqOnvJuQZxSWSsgRAvdSAJwP1OHX/OAUycm3wqQNApgY06MmXACfbFBH DxSB1/r6ucXtJgV1GBad+T0= =QpD8 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Allow psql to work against non-tablespace servers (e.g.
Greg Sabino Mullane wrote: [ There is text before PGP section. ] [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If I get time, I will begin making psql backward-compatible to 7.3 and further, but the changes to do so will not be as small as this patch and I would rather they get evaluated separately. But do we want to do this? Is it worth doing, and maintaining? I think so, within reason. Certainly going back to 7.4 is worthy, and probably 7.3 as well. Going back to 7.2 is probably not: in addition to major changes due to schemas appearing, it is a pretty old version at this point. People have certainly expressed interest in the past as far making psql backwards-compatible, and I think the code can be kept fairly clean. At least we are guaranteed to compile against current libraries - apps outside the source tree never get that luxury and have worse compatibility problems. :) The issue is that no one has been asking for this functionality, and I can imagine it becoming quite a mess after a few releases. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Allow psql to work against non-tablespace servers (e.g.
One of the things I still intend to do is make psql work against all
previous backends, so this patch is a good first step :)
For example, we have web servers on database servers on different
machines. Recompiling psql on the web servers is a PITA since it means
recompiling PHP then recompiling all the updated stuff that PHP depends
on - it's a nightmare.
Ideally we could just update the server and then update web servers much
later or never... If I can't use \db to see tablespaces, then I'll live :)
Chris
Bruce Momjian wrote:
I don't see any other code in psql that allows it to run with older
server versions so it doesn't make sense to me to fix things just for
tablespaces, and doing it for everything seems like it would uglify the
code too much.
---
Greg Sabino Mullane wrote:
Index: describe.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/describe.c,v
retrieving revision 1.103
diff -c -r1.103 describe.c
*** describe.c 15 Jul 2004 03:56:06 - 1.103
--- describe.c 11 Aug 2004 21:15:34 -
***
*** 112,117
--- 112,123
PGresult *res;
printQueryOpt myopt = pset.popt;
+ if (pset.sversion 70500) {
+ fprintf(stderr, _(This server version (%d) does not support tablespaces.\n),
+ pset.sversion);
+ return true;
+ }
+
initPQExpBuffer(buf);
printfPQExpBuffer(buf,
***
*** 706,713
/* Get general table info */
printfPQExpBuffer(buf,
SELECT relhasindex, relkind, relchecks, reltriggers, relhasrules, \n
! relhasoids, reltablespace \n
FROM pg_catalog.pg_class WHERE oid = `%s`,
oid);
res = PSQLexec(buf.data, false);
if (!res)
--- 712,720
/* Get general table info */
printfPQExpBuffer(buf,
SELECT relhasindex, relkind, relchecks, reltriggers, relhasrules, \n
! relhasoids %s \n
FROM pg_catalog.pg_class WHERE oid = `%s`,
+ pset.sversion = 70500 ? , reltablespace : ,
oid);
res = PSQLexec(buf.data, false);
if (!res)
***
*** 729,735
tableinfo.hasindex = strcmp(PQgetvalue(res, 0, 0), t) == 0;
tableinfo.hasrules = strcmp(PQgetvalue(res, 0, 4), t) == 0;
tableinfo.hasoids = strcmp(PQgetvalue(res, 0, 5), t) == 0;
! tableinfo.tablespace = atooid(PQgetvalue(res, 0, 6));
PQclear(res);
headers[0] = _(Column);
--- 736,743
tableinfo.hasindex = strcmp(PQgetvalue(res, 0, 0), t) == 0;
tableinfo.hasrules = strcmp(PQgetvalue(res, 0, 4), t) == 0;
tableinfo.hasoids = strcmp(PQgetvalue(res, 0, 5), t) == 0;
! tableinfo.tablespace = (pset.sversion = 70500) ?
! atooid(PQgetvalue(res, 0, 6)) : 0;
PQclear(res);
headers[0] = _(Column);
***
*** 932,939
footers = pg_malloc_zero(4 * sizeof(*footers));
footers[count_footers++] = pg_strdup(tmpbuf.data);
! add_tablespace_footer(tableinfo.relkind, tableinfo.tablespace,
! footers, count_footers, tmpbuf);
footers[count_footers] = NULL;
}
--- 940,947
footers = pg_malloc_zero(4 * sizeof(*footers));
footers[count_footers++] = pg_strdup(tmpbuf.data);
! add_tablespace_footer(tableinfo.relkind, tableinfo.tablespace,
! footers, count_footers, tmpbuf);
footers[count_footers] = NULL;
}
Index: settings.h
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/settings.h,v
retrieving revision 1.18
diff -c -r1.18 settings.h
*** settings.h 12 May 2004 13:38:45 - 1.18
--- settings.h 11 Aug 2004 21:15:34 -
***
*** 41,47
FILE *cur_cmd_source; /* describe the status of the current main
* loop */
bool cur_cmd_interactive;
!
const char *progname; /* in case you renamed psql */
char *inputfile; /* for error reporting */
unsigned lineno; /* also for error reporting */
--- 41,47
FILE *cur_cmd_source; /* describe the status of the current main
* loop */
bool cur_cmd_interactive;
! int sversion; /* backend server version */
const char *progname; /* in case you renamed psql */
char *inputfile; /* for error reporting */
unsigned lineno; /* also for error reporting */
Index: startup.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v
retrieving revision 1.95
diff -c -r1.95 startup.c
*** startup.c 3 Jun 2004 00:07:37 - 1.95
--- startup.c 11 Aug 2004 21:15:34 -
***
*** 217,222
--- 217,225
SyncVariables();
+ /* Grab the backend server version */
+ pset.sversion = PQserverVersion(pset.db);
+
if (options.action == ACT_LIST_DB)
{
int success = listAllDbs(false);
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Allow psql to work against non-tablespace servers (e.g.
If I get time, I will begin making psql backward-compatible to 7.3 and further, but the changes to do so will not be as small as this patch and I would rather they get evaluated separately. But do we want to do this? Is it worth doing, and maintaining? Yes please, I'll maintain it as well :) Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Allow psql to work against non-tablespace servers (e.g.
At least we are guaranteed to compile against current libraries - apps outside the source tree never get that luxury and have worse compatibility problems. :) The issue is that no one has been asking for this functionality, and I can imagine it becoming quite a mess after a few releases. No messier than pg_dump (which yes, is quite messy :) ) Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Allow psql to work against non-tablespace servers (e.g.
Christopher Kings-Lynne wrote: If I get time, I will begin making psql backward-compatible to 7.3 and further, but the changes to do so will not be as small as this patch and I would rather they get evaluated separately. But do we want to do this? Is it worth doing, and maintaining? Yes please, I'll maintain it as well :) OK, I just needed to see it was something that we were going to go into with a full effort. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Allow psql to work against non-tablespace servers (e.g.
Christopher Kings-Lynne wrote: At least we are guaranteed to compile against current libraries - apps outside the source tree never get that luxury and have worse compatibility problems. :) The issue is that no one has been asking for this functionality, and I can imagine it becoming quite a mess after a few releases. No messier than pg_dump (which yes, is quite messy :) ) It seems to me it will be a lot messier - pg_dump's functionality is quite limited. e.g. what will you do with dollar quoting or \copy's csv mode for pre-8.0 backends? cheers andrew ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [pgsql-hackers-win32] 8.0 Beta 1 // Environment Vars // .pgpass
I have applied the attached patch which adds get_home_path() which uses
USERPROFILE on Win32 and HOME on Unix.
This should fix the reported problem.
---
Andrew Dunstan wrote:
Joerg Hessdoerfer wrote:
On Thursday 12 August 2004 06:25, Tom Lane wrote:
efesar (the kay) [EMAIL PROTECTED] writes:
The 8.0 version does not acknowledge env vars like PGPASSWORD and seems
to ignore the contents of the .pgpass file.
Hmmm. Those are probably the same problem, since finding .pgpass
depends on expanding the $HOME env var. But I have no idea why
env vars aren't working for you ...
Yep. AFAIK, $HOME doesn't always exist in WIN32, but $HOMEDRIVE and $HOMEPATH
(or %HOMEPATH% and %HOMEDRIVE% ;-) do. Perhaps PG needs to do some munging to
build the home path from those two?
On my XP-Pro machine the appropriate setting appears to be %USERPROFILE%
- %HOMEPATH% is just \
See here for a complete list of available environment vars:
http://www.winnetmag.com/Article/ArticleID/23873/23873.html
cheers
andrew
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/bin/psql/common.c
===
RCS file: /cvsroot/pgsql-server/src/bin/psql/common.c,v
retrieving revision 1.87
diff -c -c -r1.87 common.c
*** src/bin/psql/common.c 23 May 2004 22:20:10 - 1.87
--- src/bin/psql/common.c 18 Aug 2004 02:48:08 -
***
*** 1078,1090
if (**filename == '~')
{
char *fn;
- char *home;
charoldp,
*p;
struct passwd *pw;
fn = *filename;
! home = NULL;
p = fn + 1;
while (*p != '/' *p != '\0')
--- 1078,1090
if (**filename == '~')
{
char *fn;
charoldp,
*p;
struct passwd *pw;
+ charhome[MAXPGPATH];
fn = *filename;
! *home = '\0';
p = fn + 1;
while (*p != '/' *p != '\0')
***
*** 1094,1105
*p = '\0';
if (*(fn + 1) == '\0')
! home = getenv(HOME);
else if ((pw = getpwnam(fn + 1)) != NULL)
! home = pw-pw_dir;
*p = oldp;
! if (home)
{
char *newfn;
--- 1094,1105
*p = '\0';
if (*(fn + 1) == '\0')
! get_home_path(home);
else if ((pw = getpwnam(fn + 1)) != NULL)
! StrNCpy(home, pw-pw_dir, MAXPGPATH);
*p = oldp;
! if (strlen(home) != 0)
{
char *newfn;
Index: src/bin/psql/input.c
===
RCS file: /cvsroot/pgsql-server/src/bin/psql/input.c,v
retrieving revision 1.34
diff -c -c -r1.34 input.c
*** src/bin/psql/input.c25 Jan 2004 03:07:22 - 1.34
--- src/bin/psql/input.c18 Aug 2004 02:48:08 -
***
*** 171,177
#ifdef USE_READLINE
if (flags 1)
{
! const char *home;
useReadline = true;
initialize_readline();
--- 171,177
#ifdef USE_READLINE
if (flags 1)
{
! char home[MAXPGPATH];
useReadline = true;
initialize_readline();
***
*** 180,187
if (GetVariable(pset.vars, HISTSIZE) == NULL)
SetVariable(pset.vars, HISTSIZE, 500);
using_history();
! home = getenv(HOME);
! if (home)
{
char *psql_history;
--- 180,186
if (GetVariable(pset.vars, HISTSIZE) == NULL)
SetVariable(pset.vars, HISTSIZE, 500);
using_history();
! if (get_home_path(home))
{
char *psql_history;
***
*** 231,240
#ifdef USE_READLINE
if (useHistory)
{
! char *home;
! home = getenv(HOME);
! if
Re: [PATCHES] to_timestamp overloaded to convert from Unix epoch
This has been saved for the 8.1 release: http:/momjian.postgresql.org/cgi-bin/pgpatches2 --- Michael Glaesemann wrote: Please find attached a patch (diff -c against cvs HEAD) to add a function that accepts a double precision argument assumed to be a Unix epoch timestamp and returns timestamp with time zone, and accompanying documentation. Usage: test=# select to_timestamp(200120400); to_timestamp 1976-05-05 14:00:00+09 (1 row) If regression tests are required, I will produce some. I'd appreciate any pointers as to what to look for, as they would be my first attempt at writing regression tests. Regards Michael Glaesemann grzm myrealbox com [ Attachment, skipping... ] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] pg_dump 'die on errors' option
I might rename this option for constency. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Fabien COELHO wrote: Dear patchers, Please find attached a submission to add a die on errors option to pg_restore, as it seems that some people have scripts that rely on the previous abort on error default behavior when restoring data with a direct connection. It works for me. Maybe Philip could test that it works for him? Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Add GUC_REPORT to server_encoding, integer_datetimes
Is this 8.0 material? --- Oliver Jowett wrote: This adds GUC_REPORT to server_encoding and integer_datetimes so they are reported in the V3 protocol startup packet. Also some related doc updates. Rationale: 1) server_encoding is useful to allow clients to detect bad server/client encoding pairs. The one that bites JDBC regularly is client_encoding = UNICODE with server_encoding = SQL_ASCII. I'd prefer for the server to reject that combination entirely, but failing that clients can implement such a policy themselves by inspecting server_encoding when establishing a connection. 2) integer_datetimes affects the binary representation of date/time types. A client that wants to use binary parameters or resultsets that involve those types needs to know the value of this setting before dealing with the binary data. In both cases, it's good to have it in the startup packet to avoid an extra round-trip on connection establishment. Any chance that this can go into 8.0? -O ? GNUmakefile ? config.log ? config.status ? src/Makefile.global ? src/include/pg_config.h ? src/include/stamp-h Index: doc/src/sgml/libpq.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/libpq.sgml,v retrieving revision 1.158 diff -u -c -r1.158 libpq.sgml *** doc/src/sgml/libpq.sgml 11 Aug 2004 18:06:00 - 1.158 --- doc/src/sgml/libpq.sgml 13 Aug 2004 03:29:45 - *** *** 854,864 para Parameters reported as of the current release include ! literalserver_version/ (cannot change after startup); ! literalclient_encoding/, literalis_superuser/, ! literalsession_authorization/literal, and ! literalDateStyle/. /para para --- 854,866 para Parameters reported as of the current release include ! xref linkend=guc-server-version, ! xref linkend=guc-server-encoding, ! xref linkend=guc-client-encoding, literalis_superuser/, ! literalsession_authorization/, ! xref linkend=guc-datestyle, and ! xref linkend=guc-integer-datetimes. /para para Index: doc/src/sgml/protocol.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/protocol.sgml,v retrieving revision 1.52 diff -u -c -r1.52 protocol.sgml *** doc/src/sgml/protocol.sgml11 Jun 2004 01:08:33 - 1.52 --- doc/src/sgml/protocol.sgml13 Aug 2004 03:29:46 - *** *** 1046,1057 para At present there is a hard-wired set of parameters for which ParameterStatus will be generated: they are ! literalserver_version/ (a pseudo-parameter that cannot change after ! startup); ! literalclient_encoding/, literalis_superuser/, ! literalsession_authorization/literal, and ! literalDateStyle/. This set might change in the future, or even become configurable. Accordingly, a frontend should simply ignore ParameterStatus for parameters that it does not understand or care about. --- 1046,1058 para At present there is a hard-wired set of parameters for which ParameterStatus will be generated: they are ! xref linkend=guc-server-version, ! xref linkend=guc-server-encoding, ! xref linkend=guc-client-encoding, literalis_superuser/, ! literalsession_authorization/, ! xref linkend=guc-datestyle, and ! xref linkend=guc-integer-datetimes. This set might change in the future, or even become configurable. Accordingly, a frontend should simply ignore ParameterStatus for parameters that it does not understand or care about. Index: doc/src/sgml/runtime.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.276 diff -u -c -r1.276 runtime.sgml *** doc/src/sgml/runtime.sgml 12 Aug 2004 19:03:17 - 1.276 --- doc/src/sgml/runtime.sgml 13 Aug 2004 03:29:46 - *** *** 2674,2681 variablelist ! varlistentry id=guc-datestyle xreflabel=datestyle ! termvarnamedatestyle/varname (typestring/type)/term indextermprimarydate style// listitem para --- 2674,2681 variablelist ! varlistentry id=guc-datestyle xreflabel=DateStyle ! termvarnameDateStyle/varname (typestring/type)/term indextermprimarydate style// listitem para *** *** 2747,2752 --- 2747,2763 /listitem /varlistentry + varlistentry id=guc-server-encoding xreflabel=server_encoding + termvarnameserver_encoding/varname (typestring/type)/term + indextermprimarycharacter set// + listitem +para +
Re: [PATCHES] ALTER INDEX
Your adjustment has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Stefan Kaltenbrunner wrote:
Gavin Sherry wrote:
Index: src/bin/psql/tab-complete.c
===
RCS file: /usr/local/cvsroot/pgsql-server/src/bin/psql/tab-complete.c,v
retrieving revision 1.109
diff -2 -c -r1.109 tab-complete.c
*** src/bin/psql/tab-complete.c 28 Jul 2004 14:23:30 - 1.109
--- src/bin/psql/tab-complete.c 13 Aug 2004 06:34:55 -
***
*** 633,637
{
static const char *const list_ALTER[] =
! {DATABASE, GROUP, SCHEMA, TABLE, TRIGGER, USER, NULL};
COMPLETE_WITH_LIST(list_ALTER);
--- 633,638
{
static const char *const list_ALTER[] =
! {DATABASE, GROUP, SCHEMA, TABLE, TRIGGER, USER, INDEX,
!NULL};
COMPLETE_WITH_LIST(list_ALTER);
***
*** 647,650
--- 648,661
COMPLETE_WITH_LIST(list_ALTERDATABASE);
}
+ /* ALTER INDEX name */
+ else if (pg_strcasecmp(prev3_wd, ALTER) == 0
+ pg_strcasecmp(prev2_wd, INDEX) == 0)
+ {
+ static const char *const list_ALTERDATABASE[] =
+ {SET TABLESPACE, OWNER TO, RENAME TO, NULL};
+
+ COMPLETE_WITH_LIST(list_ALTERDATABASE);
minor issue/nit(?): reusing list_ALTERDATABASE for the ALTER INDEX part
looks a little strange ...
Stefan(who could really need some feedback on his own tab-complete patch
*g*)
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (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: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [PATCHES] Compiling libpq with VC6
The problem with this approach is that it has us using the non-reliable libc rename/unlink rather than our own in libpq. I have already applied a fix that allows the code to compile cleanly. --- Andreas Pflug wrote: libpq currently doesn't compile with vc6. The reason is a conflict of prototypes for rename and unlink, which happens when fe-lobj.c includes io.h. The attached patch will redefine unlink and rename only if FRONTEND is not defined. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 8: explain analyze is your friend
Re: [PATCHES] PL/Perl document patch
Patch applied. Thanks. --- David Fetter wrote: Kind people, The enclose patch clarifies and makes a more useful example for the Global Values in PL/Perl section of the documents. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! [ Attachment, skipping... ] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Don't 'kill -9' the postmaster
Re: [PATCHES] pg_restore recognizing $-quotes
This is quite a large patch, but we do need a solution to this problem. Should it be applied? --- Philip Warner wrote: Not sure if this is the desired approach, but since it works, I thought I'd send it. This patch allows pg_restore to recognize $-quotes in SQL queries. It will treat any unquoted string that starts with a $ and has no preceding identifier chars as a potential $-quote tag, it then makes sure that the tag chars are valid. If so, it processes the $-quote. Tested against local DBs and regression DB. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp.mit.edu:11371 |/ [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Add GUC_REPORT to server_encoding, integer_datetimes
Bruce Momjian wrote: Is this 8.0 material? Tom's already applied it.. -O ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Add GUC_REPORT to server_encoding, integer_datetimes
Bruce Momjian [EMAIL PROTECTED] writes: Is this 8.0 material? Quite ... in fact it's applied already ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
