Re: [PATCHES] [HACKERS] Unclarity of configure options
Nikolay Samokhvalov wrote: The current (CVS version) configure script has the following options (among many others): --enable-dtrace build with DTrace support --with-ossp-uuidbuild with OSSP UUID library for UUID generation --with-libxml build with XML support --with-libxslt build with XSLT support One could think that adding any of this option to ./configure before building Postgres from sources, he will have corresponding support after installation and initdb process. But what we have now is the huge difference between --with-libxml and --with-libxslt: while the first one adds XML support to the core, the second one doesn't provide anything automatically, it allows only using contirb/xml2 (what is unclear because the help message is the same as for --with-libxml -- build with ... support). I have modified the configure message to be: --with-libxslt build /contrib/xml2 with XSLT support Patch attached. Also, comparing --enable-dtrace and --with-libxml I cannot see any difference in its semantics: --enable-dtrace also depends on external library and configure process fails if the system doesn't have it. So why --enable- is used in the first case and --with- in the second one? I think the reason for this is because XML is seen as something added to the backend (new capability) while dtrace is embedded in the backend. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: configure === RCS file: /cvsroot/pgsql/configure,v retrieving revision 1.566 diff -c -c -r1.566 configure *** configure 29 Oct 2007 11:25:42 - 1.566 --- configure 4 Nov 2007 17:52:55 - *** *** 898,904 --with-libedit-preferred prefer BSD Libedit over GNU Readline --with-ossp-uuidbuild with OSSP UUID library for UUID generation --with-libxml build with XML support ! --with-libxslt build with XSLT support --with-system-tzdata=DIR use system time zone data in DIR --without-zlib do not use Zlib --with-gnu-ld assume the C compiler uses GNU ld [default=no] --- 898,904 --with-libedit-preferred prefer BSD Libedit over GNU Readline --with-ossp-uuidbuild with OSSP UUID library for UUID generation --with-libxml build with XML support ! --with-libxslt build /contrib/xml2 with XSLT support --with-system-tzdata=DIR use system time zone data in DIR --without-zlib do not use Zlib --with-gnu-ld assume the C compiler uses GNU ld [default=no] Index: configure.in === RCS file: /cvsroot/pgsql/configure.in,v retrieving revision 1.532 diff -c -c -r1.532 configure.in *** configure.in 29 Oct 2007 11:25:42 - 1.532 --- configure.in 4 Nov 2007 17:52:55 - *** *** 600,607 # # XSLT # ! PGAC_ARG_BOOL(with, libxslt, no, [ --with-libxslt build with XSLT support], ! [AC_DEFINE([USE_LIBXSLT], 1, [Define to 1 to build with XSLT support. (--with-libxslt)])]) AC_SUBST(with_libxslt) --- 600,607 # # XSLT # ! PGAC_ARG_BOOL(with, libxslt, no, [ --with-libxslt build /contrib/xml2 with XSLT support], ! [AC_DEFINE([USE_LIBXSLT], 1, [Define to 1 to build /contrib/xml2 with XSLT support. (--with-libxslt)])]) AC_SUBST(with_libxslt) Index: doc/src/sgml/installation.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v retrieving revision 1.294 diff -c -c -r1.294 installation.sgml *** doc/src/sgml/installation.sgml 6 Oct 2007 15:50:43 - 1.294 --- doc/src/sgml/installation.sgml 4 Nov 2007 17:52:56 - *** *** 973,981 termoption--with-libxslt/option/term listitem para ! Build with libxslt. The filenamecontrib/xml2/ module ! relies on this library to perform Stylesheet transformations of ! XML. /para /listitem /varlistentry --- 973,981 termoption--with-libxslt/option/term listitem para ! Build filename/contrib/xml2/ with libxslt. ! filename/contrib/xml2/ relies on this library to perform ! Stylesheet transformations of XML. /para /listitem /varlistentry ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Unclarity of configure options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 4 Nov 2007 13:11:00 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: Nikolay Samokhvalov wrote: The current (CVS version) configure script has the following options (among many others): --enable-dtrace build with DTrace support --with-ossp-uuidbuild with OSSP UUID library for UUID generation --with-libxml build with XML support --with-libxslt build with XSLT support One could think that adding any of this option to ./configure before building Postgres from sources, he will have corresponding support after installation and initdb process. But what we have now is the huge difference between --with-libxml and --with-libxslt: while the first one adds XML support to the core, the second one doesn't provide anything automatically, it allows only using contirb/xml2 (what is unclear because the help message is the same as for --with-libxml -- build with ... support). I have modified the configure message to be: --with-libxslt build /contrib/xml2 with XSLT support Patch attached. Shouldn't --with-libxml be noted as deprecated? Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHLgwBATb/zqfZUUQRAsLYAJ9xIrfHnidg0BPW6durNvl61VVT8wCfdY4i kKSUyVxwaFazYlcY7SCkiCY= =A8DO -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Unclarity of configure options
Joshua D. Drake [EMAIL PROTECTED] writes: Shouldn't --with-libxml be noted as deprecated? Huh? regards, tom lane ---(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] Unclarity of configure options
Bruce Momjian [EMAIL PROTECTED] writes: I have modified the configure message to be: --with-libxslt build /contrib/xml2 with XSLT support This turns the message from something merely a tad unclear into an outright lie. --with-libxslt does not cause contrib/xml2 (or any other part of contrib) to get built. Better would be --with-libxslt build with XSLT (affects only contrib/xml2) 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] [HACKERS] Unclarity of configure options
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have modified the configure message to be: --with-libxslt build /contrib/xml2 with XSLT support This turns the message from something merely a tad unclear into an outright lie. --with-libxslt does not cause contrib/xml2 (or any other part of contrib) to get built. Better would be --with-libxslt build with XSLT (affects only contrib/xml2) Updated wording: --with-libxslt use XSLT support when building /contrib/xml2 -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] Unclarity of configure options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 04 Nov 2007 13:24:54 -0500 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Shouldn't --with-libxml be noted as deprecated? Huh? Because in 8.3 it is in core or am I misunderstanding the difference? Joshua D. Drake regards, tom lane ---(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 - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHLhmXATb/zqfZUUQRAuBJAJ9jFV8DaxWzWJKhjIPTkeXZ1OWRVQCfTaiV 5ytxcL5Q+Xc3tEAxoj7bbPY= =tLkt -END PGP SIGNATURE- ---(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] Unclarity of configure options
Joshua D. Drake wrote: On Sun, 04 Nov 2007 13:24:54 -0500 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Shouldn't --with-libxml be noted as deprecated? Huh? Because in 8.3 it is in core or am I misunderstanding the difference? you missunderstand - the XML support in 8.3 requires libxml and is only compiled in if that configure switch is selected ... Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Unclarity of configure options
Joshua D. Drake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 04 Nov 2007 13:24:54 -0500 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Shouldn't --with-libxml be noted as deprecated? Huh? Because in 8.3 it is in core or am I misunderstanding the difference? The functionality is in 8.3 and we areC keeping the /contrib/xml2 API around for those who need it. The release notes have: * contrib/xml2 is deprecated and planned for removal in 8.4 (Peter) The new XML support in core Postgres supersedes this module. Do we need more than that? I don't think so. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] Unclarity of configure options
Stefan Kaltenbrunner wrote: Joshua D. Drake wrote: On Sun, 04 Nov 2007 13:24:54 -0500 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Shouldn't --with-libxml be noted as deprecated? Huh? Because in 8.3 it is in core or am I misunderstanding the difference? you missunderstand - the XML support in 8.3 requires libxml and is only compiled in if that configure switch is selected ... Right, that too. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] Unclarity of configure options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 4 Nov 2007 14:17:48 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: The functionality is in 8.3 and we areC keeping the /contrib/xml2 API around for those who need it. The release notes have: * contrib/xml2 is deprecated and planned for removal in 8.4 (Peter) The new XML support in core Postgres supersedes this module. Do we need more than that? I don't think so. Well that was exactly my point, contrib/xml2 is deprecated as of 8.3 so it may make sense to make sure the configure says exactly that. If not, it isn't that big of a deal. I was just making a suggestion to try and help stop confusion in the future. Sincerely, Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHLhz1ATb/zqfZUUQRAmBcAJ9ToftpalD9kH5x+Vwy+SVHn6qB8ACbBB4d D+lV9utI9iNhlK7F0qjhFMk= =uovh -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Unclarity of configure options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 4 Nov 2007 14:18:23 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: Stefan Kaltenbrunner wrote: Joshua D. Drake wrote: On Sun, 04 Nov 2007 13:24:54 -0500 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Shouldn't --with-libxml be noted as deprecated? Huh? Because in 8.3 it is in core or am I misunderstanding the difference? you missunderstand - the XML support in 8.3 requires libxml and is only compiled in if that configure switch is selected ... Right, that too. Aha! O.k. that is what I missed. Suggestion withdrawn. Sincerely, Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHLh0oATb/zqfZUUQRAhVEAJ4nW8AS+gR7EOKl4UY4e7NCc/hFHACgmtpU brAYEQ+UhIMBWL9wxQFM+CA= =B7xe -END PGP SIGNATURE- ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] Unclarity of configure options
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have modified the configure message to be: --with-libxslt build /contrib/xml2 with XSLT support This turns the message from something merely a tad unclear into an outright lie. --with-libxslt does not cause contrib/xml2 (or any other part of contrib) to get built. Better would be --with-libxslt build with XSLT (affects only contrib/xml2) What is more, if we're going to do this we should mark *all* the options that only affect contrib, which is why I objected to doing this on its own in the first place. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] Unclarity of configure options
Andrew Dunstan wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have modified the configure message to be: --with-libxslt build /contrib/xml2 with XSLT support This turns the message from something merely a tad unclear into an outright lie. --with-libxslt does not cause contrib/xml2 (or any other part of contrib) to get built. Better would be --with-libxslt build with XSLT (affects only contrib/xml2) What is more, if we're going to do this we should mark *all* the options that only affect contrib, which is why I objected to doing this on its own in the first place. Uh, what other configure options to we have that only affect /contrib? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] Unclarity of configure options
Bruce Momjian wrote: Andrew Dunstan wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have modified the configure message to be: --with-libxslt build /contrib/xml2 with XSLT support This turns the message from something merely a tad unclear into an outright lie. --with-libxslt does not cause contrib/xml2 (or any other part of contrib) to get built. Better would be --with-libxslt build with XSLT (affects only contrib/xml2) What is more, if we're going to do this we should mark *all* the options that only affect contrib, which is why I objected to doing this on its own in the first place. Uh, what other configure options to we have that only affect /contrib? --with-ossp-uuid at least, IIRC This was discussed previously, BTW. Maybe you haven't read all the mail. Note that cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ALTER TYPE RENAME
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Petr Jelinek wrote:
Hi,
I noticed we don't have ALTER TYPE foo RENAME TO bar command which would
be handy for me especially for enum types.
So I wrote this little patch (including very brief doc) which adds above
syntax. It basically just does some checks and calls existing TypeRename
function which is used for renaming table rowtype now.
I hope I haven't missed anything, but I am unsure about two things.
First, this patch allows renaming base types which I don't know if it's
desired. And second we might want to throw error when renaming rowtype
(there is check in AlterTypeOwner for this but not in AlterTypeNamespace
so I don't know).
--
Regards
Petr Jelinek (PJMODOS)
Index: doc/src/sgml/ref/alter_type.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/alter_type.sgml,v
retrieving revision 1.4
diff -c -r1.4 alter_type.sgml
*** doc/src/sgml/ref/alter_type.sgml 16 Sep 2006 00:30:16 - 1.4
--- doc/src/sgml/ref/alter_type.sgml 29 Sep 2007 05:43:14 -
***
*** 26,31
--- 26,32
synopsis
ALTER TYPE replaceable class=PARAMETERname/replaceable OWNER TO
replaceable class=PARAMETERnew_owner/replaceable
ALTER TYPE replaceable class=PARAMETERname/replaceable SET SCHEMA
replaceable class=PARAMETERnew_schema/replaceable
+ ALTER TYPE replaceable class=PARAMETERname/replaceable RENAME TO
replaceable class=PARAMETERnew_name/replaceable
/synopsis
/refsynopsisdiv
***
*** 83,88
--- 84,98
/listitem
/varlistentry
+ varlistentry
+ termreplaceable class=PARAMETERnew_name/replaceable/term
+ listitem
+para
+ The new name for the type.
+/para
+ /listitem
+ /varlistentry
+
/variablelist
/para
/refsect1
Index: src/backend/commands/alter.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/alter.c,v
retrieving revision 1.25
diff -c -r1.25 alter.c
*** src/backend/commands/alter.c 21 Aug 2007 01:11:14 - 1.25
--- src/backend/commands/alter.c 29 Sep 2007 05:12:31 -
***
*** 154,159
--- 154,164
RenameTSConfiguration(stmt-object, stmt-newname);
break;
+ case OBJECT_TYPE:
+ case OBJECT_DOMAIN:
+ RenameType(stmt-object, stmt-newname);
+ break;
+
default:
elog(ERROR, unrecognized rename stmt type: %d,
(int) stmt-renameType);
Index: src/backend/commands/typecmds.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/typecmds.c,v
retrieving revision 1.107
diff -c -r1.107 typecmds.c
*** src/backend/commands/typecmds.c 4 Sep 2007 16:41:42 - 1.107
--- src/backend/commands/typecmds.c 29 Sep 2007 05:11:22 -
***
*** 2514,2519
--- 2514,2567
}
/*
+ * Execute ALTER TYPE RENAME
+ */
+ void
+ RenameType(List *names, const char *newTypeName)
+ {
+ TypeName *typename;
+ Oid typeOid;
+ Relationrel;
+ HeapTuple tup;
+ Form_pg_type typTup;
+
+ /* Make a TypeName so we can use standard type lookup machinery */
+ typename = makeTypeNameFromNameList(names);
+ typeOid = typenameTypeId(NULL, typename);
+
+ /* Look up the type in the type table */
+ rel = heap_open(TypeRelationId, RowExclusiveLock);
+
+ tup = SearchSysCacheCopy(TYPEOID,
+
ObjectIdGetDatum(typeOid),
+ 0, 0, 0);
+ if (!HeapTupleIsValid(tup))
+ elog(ERROR, cache lookup failed for type %u, typeOid);
+ typTup = (Form_pg_type) GETSTRUCT(tup);
+
+ /* check permissions on type */
+ if (!pg_type_ownercheck(typeOid, GetUserId()))
+ aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_TYPE,
+format_type_be(typeOid));
+
+ /* don't allow direct alteration of array types */
+ if (OidIsValid(typTup-typelem)
+ get_array_type(typTup-typelem) == typeOid)
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg(cannot alter array type %s,
+ format_type_be(typeOid)),
+ errhint(You can alter type %s, which will
alter the array type as well.,
Re: [PATCHES] [HACKERS] Text - C string
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Brendan Jurd wrote: As discussed on -hackers, I'm trying to get rid of some redundant code by creating a widely useful set of functions to convert between text and C string in the backend. The new extern functions, declared in include/utils/builtins.h and defined in backend/utils/adt/varlena.c, are: char * text_cstring(const text *t) char * text_cstring_limit(const text *t, int len) text * cstring_text(const char *s) text * cstring_text_limit(const char *s, int len) Within varlena.c, the actual conversions are performed by: char * do_text_cstring(const text *t, const int len) text * do_cstring_text(const char *s, const int len) These functions now do the work for the fmgr functions textin and textout, as well as being directly accessible by backend code. I've searched through the backend for any code which converted between text and C string manually (with memcpy and VARDATA), replacing with calls to one of the four new functions as appropriate. I came across some areas which were using the same, or similar, conversion technique on other varlena data types, such as bytea or xmltype. In cases where the conversion was completely identical I used the new functions. In cases with any differences (even if they seemed minor) I played it safe and left them alone. I'd now like to submit my work so far for review. This patch compiled cleanly on Linux and passed all parallel regression tests. It appears to be performance-neutral based on a few rough tests; I haven't tried to profile the changes in detail. There is still a lot of code out there using DirectFunctionCall1 to call text(in|out)). I've decided to wait for some community feedback on the patch as it stands before replacing those calls. There are a great many, and it would be a shame to have to go through them more than once. I would naively expect that replacing fmgr calls with direct calls would lead to a performance gain (no fmgr overhead), but honestly I'm not sure whether that would actually make a difference. Thanks for your time, BJ [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] quote_literal with NULL
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Brendan Jurd wrote: Hi patchers, Per discussion on -hackers, I've implemented a new internal function quote_nullable, as an alternative to quote_literal. The difference is that quote_nullable returns the text value 'NULL' on NULL input, which is suitable for insertion into an SQL statement. The idea is that when you're writing a plpgsql function with dynamic queries, you can use quote_nullable for values which are possibly-null. You're still responsible for handling NULLs sensibly within your query, but at least you get a syntactically valid SQL statement. I've included doc updates but no new regression tests. I did not add tests because there are currently no tests for quote_literal and when I recently suggested addition of tests for quote_ident [1] they were rejected. I still don't fully understand the criteria for inclusion of regression tests, but this is a similar situation, so I'm following the same guidance. Patch compiles cleanly and passes make check on x86 gentoo. Thanks for your time, BJ [1] http://archives.postgresql.org/pgsql-patches/2007-10/msg00080.php On 10/11/07, Tom Lane [EMAIL PROTECTED] wrote: Well, it's clearly useful in INSERT and UPDATE. For WHERE cases, you might or might not be able to use it, but I note that quote_nullable() would work much more like what happens if you use a parameter symbol and then bind NULL as the actual parameter value ... In hindsight we should probably have done quote_literal the way the OP suggests, but I concur that it's too late to change it. An additional function seems a reasonable compromise. [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Avoid needless copy in nodeMaterial
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Neil Conway wrote: Attached is a patch that avoids a needless copy of the result tuple in nodeMaterial, in the case that we don't have a previously-materialized tuple to return. We can just return the TTS produced by executing our child node, rather than returning a copy of it. I didn't bother pulling the MinimalTuple out of outerslot and stuffing it back into the nodeMaterial's result slot, as AFAICS that is not necessary. Although I suppose you could make a cleanliness argument that that would be worth doing instead. (This is 8.4 material...) -Neil [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[PATCHES] Consistent \d commands in psql
Attached is an updated version of my psql patch that makes the \d backslash commands perform in an intuitive, consistent way. Specifically, the following objects will be treated as first class citizens (as tables and indexes currently are) by showing all the non-system objects by default and requiring a S to see the system ones. aggregates conversions comments domains operators functions types Currently, there is no way to view all the non-system functions in a database using backslash commands, as you can with \dt, unless all of the functions happen to be in a single schema (\df myschema.). With this patch, it would be as simple as \df, and the current behavior would be done with \dfS. This patch also adds a few new things to the tab-completion table, such as comments and conversions. Comments welcome. Last time the patch withered on the vine, despite strong support from -general, hence I'm going to try again, as I really want a way to view my functions without querying the pg_proc tables directly. :) -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200711042003 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 Index: doc/src/sgml/ref/psql-ref.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v retrieving revision 1.196 diff -c -r1.196 psql-ref.sgml *** doc/src/sgml/ref/psql-ref.sgml 29 Oct 2007 17:29:59 - 1.196 --- doc/src/sgml/ref/psql-ref.sgml 5 Nov 2007 00:44:49 - *** *** 874,885 varlistentry termliteral\da [ replaceable class=parameterpattern/replaceable ]/literal/term listitem para ! Lists all available aggregate functions, together with their ! return type and the data types they operate on. If replaceable ! class=parameterpattern/replaceable is specified, only aggregates whose names match the pattern are shown. /para /listitem --- 874,887 varlistentry termliteral\da [ replaceable class=parameterpattern/replaceable ]/literal/term + termliteral\daS [ replaceable class=parameterpattern/replaceable ]/literal/term listitem para ! Lists all available aggregate functions, together with the data ! types they operate on. The letter literalS/literal restricts ! the listing to system aggregates; without literalS/literal, ! only non-system aggregates are shown. If replaceable class=parameterpattern/replaceable is specified, only aggregates whose names match the pattern are shown. /para /listitem *** *** 904,912 --- 906,917 varlistentry termliteral\dc [ replaceable class=parameterpattern/replaceable ]/literal/term + termliteral\dcS [ replaceable class=parameterpattern/replaceable ]/literal/term listitem para Lists all available conversions between character-set encodings. + The letter literalS/literal restricts the listing to system conversions; + without literalS/literal, only non-system conversions are shown. If replaceable class=parameterpattern/replaceable is specified, only conversions whose names match the pattern are listed. *** *** 927,943 varlistentry termliteral\dd [ replaceable class=parameterpattern/replaceable ]/literal/term listitem para Shows the descriptions of objects matching the replaceable class=parameterpattern/replaceable, or of all visible objects if no argument is given. But in either case, only objects that have ! a description are listed. (quoteObject/quote covers aggregates, functions, operators, types, relations (tables, views, indexes, sequences, large objects), rules, and triggers.) For example: programlisting ! =gt; userinput\dd version/userinput Object descriptions Schema | Name | Object |Description +-+--+--- --- 932,951 varlistentry termliteral\dd [ replaceable class=parameterpattern/replaceable ]/literal/term + termliteral\ddS [ replaceable class=parameterpattern/replaceable ]/literal/term listitem para Shows the descriptions of objects matching the replaceable class=parameterpattern/replaceable, or of all visible objects if no argument is given. But in either case, only objects that have ! a description are listed. The letter literalS/literal restricts ! the listing to system objects; without literalS/literal, ! only non-system objects are shown. (quoteObject/quote covers aggregates, functions, operators, types, relations (tables, views, indexes, sequences,
