Re: [PATCHES] LDFLAGS overriding
[ CC'ing Peter since this is usually his area ] On Wed, 2004-09-29 at 02:10, Bruce Momjian wrote: I think your 'override' fix is correct. Personally I think override should be used in most cases in our code because we are usually careful to add to any flags already supplied by the user. Ok, I think 'override' is definitely correct for the instance the patch fixes, since the build breaks otherwise. Therefore I intend to apply the patch I posted earlier to HEAD shortly, barring any objections. In addition, we modify LDFLAGS in the following places: (1) src/Makefile.global.in -- adding rpath flags (2) src/Makefile.global.in -- adding LDFLAGS due to COPT/PROFILE (3) src/makefiles/Makefile.hpux (4) src/makefiles/Makefile.irix (5) src/makefiles/Makefile.qnx4 (6) src/makefiles/Makefile.svr4 What do folks think about using override in these situations? -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] minor doc change
On Thu, 2004-09-30 at 15:53, Robert Treat wrote: This patch makes mention to use the newer pg_dump when migrating, as suggested by a few folks. Patch applied with some editorialization. Thanks! -Neil ---(end of broadcast)--- TIP 3: 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] LDFLAGS overriding
Neil Conway schrieb: [ CC'ing Peter since this is usually his area ] On Wed, 2004-09-29 at 02:10, Bruce Momjian wrote: I think your 'override' fix is correct. Personally I think override should be used in most cases in our code because we are usually careful to add to any flags already supplied by the user. Ok, I think 'override' is definitely correct for the instance the patch fixes, since the build breaks otherwise. Therefore I intend to apply the patch I posted earlier to HEAD shortly, barring any objections. In addition, we modify LDFLAGS in the following places: (1) src/Makefile.global.in -- adding rpath flags (2) src/Makefile.global.in -- adding LDFLAGS due to COPT/PROFILE (3) src/makefiles/Makefile.hpux (4) src/makefiles/Makefile.irix (5) src/makefiles/Makefile.qnx4 (6) src/makefiles/Makefile.svr4 What do folks think about using override in these situations? I think that LDFLAGS overriding is in some situations bad for newer libtool, as it is used with some postgresql contrib makefiles and interfaces. LIBS are added to LDFLAGS where they really should be added to LIBS, not LDFLAGS. This causes incorrect order in the linker command-line, which fails in building shared libs. A similar problem as with building php. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] plperl features
Sergej Sergeev [EMAIL PROTECTED] writes:
What happens if you feed other pseudotypes, like cstring or
language_handler? Shouldn't that be disallowed or something?
Other pseudo-types are disallowed (no-change)
No, because you diked out the check at lines 1452ff, rather than
upgrading it to something correct.
I find the fn_retispseudo and arg_is_p flags pretty bogus anyway
since they fail to indicate *which* pseudotype it is. You might as
well just test for the specific type OID.
regards, tom lane
New patch. I have added the check pseudo-type argumetns.
Specific type is substituted in runtime, during function call.
--
g.gRay: PL/perl, PL/PHP ;)
Index: plperl.c
===
RCS file: /projects/cvsroot/pgsql-server/src/pl/plperl/plperl.c,v
retrieving revision 1.51
diff -c -w -r1.51 plperl.c
*** plperl.c13 Sep 2004 20:08:59 - 1.51
--- plperl.c30 Sep 2004 16:07:25 -
***
*** 82,87
--- 82,89
boollanpltrusted;
boolfn_retistuple; /* true, if function returns tuple */
boolfn_retisset;/* true, if function returns set */
+ boolfn_retisarray; /* true, if function returns true array*/
+ boolfn_retispseudo; /* true, if function returns pseudo type*/
Oid ret_oid;/* Oid of returning type */
FmgrInforesult_in_func;
Oid result_typioparam;
***
*** 89,94
--- 91,97
FmgrInfoarg_out_func[FUNC_MAX_ARGS];
Oid arg_typioparam[FUNC_MAX_ARGS];
boolarg_is_rowtype[FUNC_MAX_ARGS];
+ boolarg_is_p[FUNC_MAX_ARGS];
SV *reference;
} plperl_proc_desc;
***
*** 277,282
--- 280,319
}
/**
+ * convert perl array to the string representation
+ **/
+ static SV*
+ plperl_convert_to_pg_array(SV *src)
+ {
+ SV* rv;
+ SV**val;;
+ AV* internal;
+ int len,
+ i;
+
+ internal=(AV*)SvRV(src);
+ len = av_len(internal)+1;
+
+ rv = newSVpv({ ,0);
+ for(i=0; ilen; i++)
+ {
+ val = av_fetch(internal, i, FALSE);
+ if (SvTYPE(*val)==SVt_RV)
+ if (SvTYPE(SvRV(*val))==SVt_PVAV)
+ sv_catpvf(rv, %s,
SvPV(plperl_convert_to_pg_array(*val),PL_na));
+ else
+ elog(ERROR, plperl: check array structure);
+ else
+ sv_catpvf(rv, %s, SvPV(*val,PL_na));
+ if (i != len-1) sv_catpvf(rv, ,);
+ }
+
+ sv_catpvf(rv, });
+
+ return rv;
+ }
+
+ /**
* turn a tuple into a hash expression and add it to a list
**/
static void
***
*** 752,757
--- 789,807
XPUSHs(sv_2mortal(newSVpv(undef, 0)));
for (i = 0; i desc-nargs; i++)
{
+ if (desc-arg_is_p[i]){
+ HeapTuple typeTup;
+ Form_pg_typetypeStruct;
+
+ typeTup = SearchSysCache(TYPEOID,
+
ObjectIdGetDatum(get_fn_expr_argtype(fcinfo-flinfo, i)),
+ 0, 0, 0);
+ typeStruct = (Form_pg_type) GETSTRUCT(typeTup);
+ perm_fmgr_info(typeStruct-typoutput,
(desc-arg_out_func[i]));
+ desc-arg_typioparam[i] = getTypeIOParam(typeTup);
+ ReleaseSysCache(typeTup);
+ }
+
if (desc-arg_is_rowtype[i])
{
if (fcinfo-argnull[i])
***
*** 909,914
--- 959,977
perlret = srf_perlret;
}
+ if (prodesc-fn_retispseudo){
+ HeapTuple retTypeTup;
+ Form_pg_typeretTypeStruct;
+
+ retTypeTup = SearchSysCache(TYPEOID,
+
ObjectIdGetDatum(get_fn_expr_rettype(fcinfo-flinfo)),
+ 0, 0, 0);
+ retTypeStruct = (Form_pg_type) GETSTRUCT(retTypeTup);
+ perm_fmgr_info(retTypeStruct-typinput, (prodesc-result_in_func));
+ prodesc-result_typioparam = getTypeIOParam(retTypeTup);
+ ReleaseSysCache(retTypeTup);
+ }
+
if (prodesc-fn_retisset SRF_IS_FIRSTCALL())
{
if (prodesc-fn_retistuple)
[PATCHES] SSL on win32
Hello! Here is a patch to fix win32 ssl builds. Summary of changes: * Links with -leay32 and -lssleay32 instead of crypto and ssl. On win32, crypto and ssl is only used for static linking. * Initializes SSL in the backend and not just in the postmaster. We cannot pass the SSL context from the postmaster through the parameter file, because it contains function pointers. * Split one error check in be-secure.c. Previously we could not tell which of three calls actually failed. The previous code also returned incorrect error messages if SSL_accept() failed - that function needs to use SSL_get_error() on the return value, can't just use the error queue. * Since the win32 implementation uses non-blocking sockets behind the scenes in order to deliver signals correctly, implements a version of SSL_accept() that can handle this. Also, add a wait function in case SSL_read or SSL_write() needs more data. I'd appreciate it if one of the win32 guys can confirm that this patch fixes the build for them as well. //Magnus win32_ssl.patch Description: win32_ssl.patch ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] SSL on win32
-Original Message- From: Magnus Hagander [mailto:[EMAIL PROTECTED] Sent: 30 September 2004 23:00 To: PostgreSQL-patches Cc: Dave Page Subject: SSL on win32 Hello! Here is a patch to fix win32 ssl builds. Summary of changes: snip I'd appreciate it if one of the win32 guys can confirm that this patch fixes the build for them as well. Yup, looks good to me. Compiles OK and SSL appears to work just fine :-) Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] 8.0.0beta3 release documentation fixes for Tcl
On Thu, 2004-09-30 at 10:30, ljb wrote: These corrections against 8.0.0beta3 are for removal of the Tcl interface from core. Patch applied to HEAD, with some editorializing. autoconf (2.53) re-run. For future reference, patches should be made with a consistent directory prefix (i.e. if you're going to make some hunks of the patch relevant to the top-level of the PG source tree, please do so for all hunks). Thanks for the patch! In addition, please delete doc/man1/pgtclsh.1 and doc/man1/pgtksh.1 from the distribution, since these commands are no longer included. I couldn't see these files in the beta3 distribution. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] LDFLAGS overriding
On Thu, 2004-09-30 at 17:20, Neil Conway wrote: Ok, I think 'override' is definitely correct for the instance the patch fixes, since the build breaks otherwise. Therefore I intend to apply the patch I posted earlier to HEAD shortly, barring any objections. Patch applied. I haven't changed the other assignments to LDFLAGS; that can be done by anyone who's interested. -Neil ---(end of broadcast)--- TIP 3: 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
[PATCHES] Preliminary patch for FRONTEND
As many know, the FRONTEND usage of /src/port is very fragile. It requires every binary that uses certain libpgport object files to create its own version, which is very fragile, and could easily break if a function call is added in a subrelease, especially on certain ports. The following patch addresses this issue by making libpgport usable unchanged by client applications, and makes a special server version for the backend. This is much less fragile than trying to make sure you hit every single binary that uses libpgport. I originally tried abstracting out the #ifdef FRONTEND defines in pgport but found that that wasn't easily done so making separate libraries was cleaner. -- 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/backend/Makefile === RCS file: /cvsroot/pgsql-server/src/backend/Makefile,v retrieving revision 1.104 diff -c -c -r1.104 Makefile *** src/backend/Makefile1 Aug 2004 18:07:42 - 1.104 --- src/backend/Makefile1 Oct 2004 04:04:00 - *** *** 26,31 --- 26,33 OBJS+= bootstrap/bootstrap.o endif + # Add server version of port object files first + LIBS:=$(subst -lpgport, -lpgport_srv -lpgport, $(LIBS)) ## Index: src/bin/initdb/Makefile === RCS file: /cvsroot/pgsql-server/src/bin/initdb/Makefile,v retrieving revision 1.44 diff -c -c -r1.44 Makefile *** src/bin/initdb/Makefile 29 Aug 2004 04:13:01 - 1.44 --- src/bin/initdb/Makefile 1 Oct 2004 04:04:06 - *** *** 13,33 top_builddir = ../../.. include $(top_builddir)/src/Makefile.global ! override CPPFLAGS := -DFRONTEND -I$(libpq_srcdir) $(CPPFLAGS) ! OBJS= initdb.o dirmod.o exec.o all: submake-libpq submake-libpgport initdb initdb: $(OBJS) $(libpq_builddir)/libpq.a $(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o [EMAIL PROTECTED](X) - dirmod.c: % : $(top_srcdir)/src/port/% - rm -f $@ $(LN_S) $ . - - exec.c: % : $(top_srcdir)/src/port/% - rm -f $@ $(LN_S) $ . - install: all installdirs $(INSTALL_PROGRAM) initdb$(X) $(DESTDIR)$(bindir)/initdb$(X) --- 13,27 top_builddir = ../../.. include $(top_builddir)/src/Makefile.global ! override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS) ! OBJS= initdb.o all: submake-libpq submake-libpgport initdb initdb: $(OBJS) $(libpq_builddir)/libpq.a $(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o [EMAIL PROTECTED](X) install: all installdirs $(INSTALL_PROGRAM) initdb$(X) $(DESTDIR)$(bindir)/initdb$(X) *** *** 38,44 rm -f $(DESTDIR)$(bindir)/initdb$(X) clean distclean maintainer-clean: ! rm -f initdb$(X) $(OBJS) dirmod.c exec.c # ensure that changes in datadir propagate into object file --- 32,38 rm -f $(DESTDIR)$(bindir)/initdb$(X) clean distclean maintainer-clean: ! rm -f initdb$(X) $(OBJS) # ensure that changes in datadir propagate into object file Index: src/bin/pg_config/Makefile === RCS file: /cvsroot/pgsql-server/src/bin/pg_config/Makefile,v retrieving revision 1.8 diff -c -c -r1.8 Makefile *** src/bin/pg_config/Makefile 1 Aug 2004 06:56:38 - 1.8 --- src/bin/pg_config/Makefile 1 Oct 2004 04:04:06 - *** *** 1,18 ! # $PostgreSQL: pgsql-server/src/bin/pg_config/Makefile,v 1.8 2004/08/01 06:56:38 momjian Exp $ subdir = src/bin/pg_config top_builddir = ../../.. include $(top_builddir)/src/Makefile.global ! OBJS= pg_config.o exec.o ! override CPPFLAGS := -DFRONTEND -I$(libpq_srcdir) -DVAL_CONFIGURE=\$(configure_args)\ $(CPPFLAGS) all: submake-libpgport pg_config - exec.c: % : $(top_srcdir)/src/port/% - rm -f $@ $(LN_S) $ . - pg_config: $(OBJS) $(CC) $(CFLAGS) $(OBJS) $(LDFLAGS) $(LIBS) -o [EMAIL PROTECTED](X) --- 1,23 ! #- ! # ! # Makefile for src/bin/pg_controldata ! # ! # Copyright (c) 1998-2002, PostgreSQL Global Development Group ! # ! # $PostgreSQL: pgsql-server/src/bin/pg_controldata/Makefile,v 1.9 2004/05/26 17:24:01 tgl Exp $ ! # ! #- subdir = src/bin/pg_config top_builddir = ../../.. include $(top_builddir)/src/Makefile.global ! OBJS= pg_config.o ! override CPPFLAGS := -I$(libpq_srcdir) -DVAL_CONFIGURE=\$(configure_args)\ $(CPPFLAGS) all: submake-libpgport pg_config pg_config:
Re: [PATCHES] Preliminary patch for FRONTEND
Bruce Momjian [EMAIL PROTECTED] writes: The following patch addresses this issue by making libpgport usable unchanged by client applications, and makes a special server version for the backend. This raises some alarm bells for me. Why does a port support library need to distinguish whether it is running in frontend or backend? Certainly the standard Unix library calls that it is purporting to replace do not care. Also, the patch does both more and less than I'd expect from your description. Why are there no changes at all to C code? And how can you just remove, eg, dirmod.c and exec.c from pg_resetxlog? regards, tom lane ---(end of broadcast)--- TIP 3: 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
