[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
\da [ pattern ]
! Lists all available aggregate functions, together with their
! return type and the data types they operate on. If pattern
is specified, only aggregates whose names match the pattern are shown.
--- 874,887
\da [ pattern ]
+ \daS [ pattern ]
! Lists all available aggregate functions, together with the data
! types they operate on. The letter S restricts
! the listing to system aggregates; without S,
! only non-system aggregates are shown. If pattern
is specified, only aggregates whose names match the pattern are shown.
***
*** 904,912
--- 906,917
\dc [ pattern ]
+ \dcS [ pattern ]
Lists all available conversions between character-set encodings.
+ The letter S restricts the listing to system conversions;
+ without S, only non-system conversions are shown.
If pattern
is specified, only conversions whose names match the pattern are
listed.
***
*** 927,943
\dd [ pattern ]
Shows the descriptions of objects matching the pattern, or of all visible objects if
no argument is given. But in either case, only objects that have
! a description are listed.
(Object covers aggregates, functions, operators,
types, relations (tables, views, indexes, sequences, large
objects), rules, and triggers.) For example:
! => \dd version
Object descriptions
Schema | Name | Object |Description
+-+--+---
--- 932,951
\dd [ pattern ]
+ \ddS [ pattern ]
Shows the descriptions of objects matching the pattern, or of all visible objects if
no argument is given. But in either case, only objects that have
! a description are listed. The letter S restricts
! the listing to system objects; without S,
! only non-system objects are shown.
(Object covers aggregates, functions, operators,
types, relations (tables, views, indexes, sequences, large
objects), rules, and triggers.) For example:
! => \ddS version
Object descriptions
Schema | Name | Object |Description
+-+--+---
***
*** 957,966
\dD [ pattern ]
! Lists all available domains. If pattern
is specified, only matching domains are shown.
--- 965,976
\dD [ pattern ]
+ \dDS [ pattern ]
! Lists all available domains. The letter S restricts
! the listing to system domains; without S,
! only non-system domains are shown. If pattern
is specified, only matching domains are shown.
***
*** 970,984
\df [ pattern ]
\df+ [ pattern ]
Lists available functions, together with their argument and
! return types.
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
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] [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] 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
>
> ALTER TYPE name OWNER TO
> new_owner
> ALTER TYPE name SET SCHEMA
> new_schema
> + ALTER TYPE name RENAME TO
> new_name
>
>
>
> ***
> *** 83,88
> --- 84,98
>
>
>
> +
> + new_name
> +
> +
> + The new name for the type.
> +
> +
> +
> +
>
>
>
> 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.",
> +
> format_type_be(typTup->typelem;
> +
> + /* and do the work */
> + TypeRename(typeOid, newTypeName, typTup->typnamespace);
> +
> + /* Clean up */
> + heap_close(rel, RowExclusiveLock);
> + }
> +
>
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] [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
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
-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
-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
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
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
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
-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
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
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
"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
-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
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 --with-libxslt ! Build with libxslt. The contrib/xml2 module ! relies on this library to perform Stylesheet transformations of ! XML. --- 973,981 --with-libxslt ! Build /contrib/xml2 with libxslt. ! /contrib/xml2 relies on this library to perform ! Stylesheet transformations of XML. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
