Re: [PATCHES] Explain XML patch v2
On Fri, 2008-07-04 at 19:38 +0100, Dave Page wrote: On Fri, Jul 4, 2008 at 5:20 PM, Simon Riggs [EMAIL PROTECTED] wrote: * If the patch was implemented as an ExplainOneQuery_hook we would be able to use this with 8.3 also, which might be interesting. So there's no real need for this to be a patch on core. Would that mean that instead of being an optional format that pgAdmin could request with appropriate grammar, it would be something that was only available if the plugin was loaded, and would replace regular EXPLAIN output? If so, that would be extremely inconvenient, and next to useless for general purpose utilities. It can be optional since plugins can add parameters also. It wouldn't take long to make up a plugin for 8.3 once this patch has been committed to core for 8.4, so if you're saying you'd definitely like it in core then I'm OK with that. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
On Sat, Jul 5, 2008 at 10:41 AM, Simon Riggs [EMAIL PROTECTED] wrote: It can be optional since plugins can add parameters also. GUCs I assume you mean, not grammar. Unless I'm misreading the code though, if the plugin is there it will always run instead of the regular explain code, so presumabiy that's optional as in XML or nothing, not XML or standard output. It wouldn't take long to make up a plugin for 8.3 once this patch has been committed to core for 8.4, so if you're saying you'd definitely like it in core then I'm OK with that. If i's always there it's definitely more useful to pgAdmin, and doesn't require that we instruct users to install more server side plugin code to use the features they want. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
On Sat, 2008-07-05 at 16:00 +0100, Dave Page wrote: On Sat, Jul 5, 2008 at 10:41 AM, Simon Riggs [EMAIL PROTECTED] wrote: It can be optional since plugins can add parameters also. GUCs I assume you mean, not grammar. Unless I'm misreading the code though, if the plugin is there it will always run instead of the regular explain code, so presumabiy that's optional as in XML or nothing, not XML or standard output. You can easily make it switchable between XML and normal. It wouldn't take long to make up a plugin for 8.3 once this patch has been committed to core for 8.4, so if you're saying you'd definitely like it in core then I'm OK with that. If i's always there it's definitely more useful to pgAdmin, and doesn't require that we instruct users to install more server side plugin code to use the features they want. As I said, I'm OK with that. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
Quoting daveg [EMAIL PROTECTED]: On Wed, Jul 02, 2008 at 09:01:18AM -0700, David Fetter wrote: On Wed, Jul 02, 2008 at 05:57:29PM +0200, Peter Eisentraut wrote: It would also be interesting if EXPLAIN could optionally be a function that returns a datum of type XML, to allow further processing. It would be better to have a function which allows people to plug in their own serialization. A JSON or YAML one, for example, would be much lighter weight on both ends. +1 for either of these. -dg So, this leads me to the idea of assembling the EXPLAIN data internally in an output-neutral data structure. At the very end of processing, one decision statement would decide which output plugin to use for output. Sprinkling XML print statements throughout the code (as currently done in the patch) while functional, is not ideal. And, the escaping of XML content should ideally be done in the serializer anyway. Of course, this realization didn't occur to me until *after* I had spent a bit of time coding up the patch in its current form. Oh well. Thoughts? Regarding the XML datum, in order to support that, will all users need to compile with libxml? Are there any lighter weight solutions to serialize other than libxml? -Tom Raney -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
Am Freitag, 4. Juli 2008 schrieb Tom Raney: Regarding the XML datum, in order to support that, will all users need to compile with libxml? Are there any lighter weight solutions to serialize other than libxml? You can create XML without libxml. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Explain XML patch v2
Peter Eisentraut [EMAIL PROTECTED] writes: Am Freitag, 4. Juli 2008 schrieb Tom Raney: Regarding the XML datum, in order to support that, will all users need to compile with libxml? Are there any lighter weight solutions to serialize other than libxml? You can create XML without libxml. Seems to me that anyone who wants this feature will probably also want the existing libxml-based features, so they'll be building with libxml anyway. So I'd not be in favor of expending any extra code on a roll-your-own solution. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
On Tue, 2008-07-01 at 21:48 -0700, Tom Raney wrote: This is an update to my EXPLAIN XML patch submitted a few days ago. This is an important patch and you've done well to get it this far. I have much detailed feedback, but these are just emergent requests, now I can see and understand what you've done. * If the patch was implemented as an ExplainOneQuery_hook we would be able to use this with 8.3 also, which might be interesting. So there's no real need for this to be a patch on core. * If I understand, the DTD option inlines the DTD into the resulting XML document, rather than adding a schema definition? * The DTD should be in a separate file also, so it can be referred to. We should give that DTD a permanent URL so we can identify it across the internet. This is the first time the project has published an XML DTD/Schema, so we need to think through the right way to publish it. The DTD should have a version number in it, so when this gets updated in the future we can validate against the correct one. * The DTD is regrettably a long, long way from where I need it to be. The PLAN elements are all unrelated to one another, apart from their sequence within the XML document and their indent. That definition can lead to XML documents that match the DTD yet would never be valid plans, amongst other problems. For sensible analysis of the SQL we need the DTD to match the actual structure of nodes in the executor. This requires major DTD changes, regrettably. The indent comes from the nesting of the nodes, and is not merely a visual feature of the complete plan. IMHO it is critically important that the XML correctly conveys the structure of the plan and not just the formatting of the current text output. Otherwise many doors will be closed to us and this whole project wasted. I want to be able to write xml queries to retrieve plans that contain a merge join where both the inner and outer are merge joins, or to easily compare the structure of two complex queries looking for differences. * The meaning of the two time attributes is somewhat confused. It is startuptime and totaltime, not time_start and time_end. * It looks to me like QUALIFIER alone is not enough, since in some cases nodes have both an index condition and a filter, for example. * I've made a number of suggested changes below, but the DTD really needs to follow the structures in src/include/nodes/plannodes.h In particular you'll see the recursive structure introduced by the DTD changes below * EXPLAIN has been renamed PLAN * PLAN has been renamed NODE * COST has been renamed to ESTIMATE * ANALYZE has been renamed to ACTUAL * OUTPUT, SORT and QUALIFIER have been removed for clarity only !ELEMENT plan (estimate, runtime?) !ELEMENT node (table?, index?, estimate, actual?, outerpath?, innerpath?, initpath) !ATTLIST plan\n nodetype CDATA #REQUIRED !ELEMENT outerpath (node) !ELEMENT innerpath (node) !ELEMENT initpath (node) !ELEMENT estimate EMPTY !ATTLIST estimate startupcost CDATA #REQUIRED totalcost CDATA#REQUIRED rows CDATA #REQUIRED width CDATA#REQUIRED !ELEMENT actual EMPTY !ATTLIST actual\n startuptime CDATA #REQUIRED totaltime CDATA #REQUIRED rows CDATA #REQUIRED loops CDATA #REQUIRED * I'd much prefer to define this as a Schema, since that's a bit more flexible in what we can do, plus we can specify datatypes. * Based upon some of those issues, I'd suggest that further work on the DTD/Schema should only happen when a reasonable range of plans have been accumulated to allow full understanding of the possibilities I'm sorry I've found so much to say about this, but don't be dissuaded. The basic structure of the patch is there, we just need to get the details right also, so we can take full. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
On Fri, Jul 4, 2008 at 5:20 PM, Simon Riggs [EMAIL PROTECTED] wrote: * If the patch was implemented as an ExplainOneQuery_hook we would be able to use this with 8.3 also, which might be interesting. So there's no real need for this to be a patch on core. Would that mean that instead of being an optional format that pgAdmin could request with appropriate grammar, it would be something that was only available if the plugin was loaded, and would replace regular EXPLAIN output? If so, that would be extremely inconvenient, and next to useless for general purpose utilities. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
Tom Raney [EMAIL PROTECTED] writes: This is an update to my EXPLAIN XML patch submitted a few days ago. I've added a documentation patch and modified some of the code per comments by Gregory Stark. You should update the wiki at http://wiki.postgresql.org/wiki/CommitFest:2008-07 so any reviewers look at the updated patch. (I certainly don't see any reason to wait two months for the next commit fest) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
Am Mittwoch, 2. Juli 2008 schrieb Tom Raney: This is an update to my EXPLAIN XML patch submitted a few days ago. Could you explain how you came up with the XML schema design? I suppose you just made something up that went along with the existing XML output. I would like to see more integration with the spirit of the existing XML functionality. For example, instead of things like runtime ms=\%.3f\ /\n we ought to be using XML Schema data types for time intervals and so on. We might also want to use an XML namespace. Table and index names should be escaped using the existing escape mechanism for identifiers. There might also be encoding issues. It would also be interesting if EXPLAIN could optionally be a function that returns a datum of type XML, to allow further processing. Any thoughts on these issues? -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
On Wed, Jul 2, 2008 at 4:57 PM, Peter Eisentraut [EMAIL PROTECTED] wrote: Am Mittwoch, 2. Juli 2008 schrieb Tom Raney: This is an update to my EXPLAIN XML patch submitted a few days ago. Could you explain how you came up with the XML schema design? I suppose you just made something up that went along with the existing XML output. Speaking of schema - I haven't had time to review the patch myself yet, but does it include schema names for all relations? The current text output does not (and adding it has been rejected due to verbosity), but that makes any kind of query tuning or information gathering tool more or less impossible to write. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
On Wed, Jul 02, 2008 at 09:01:18AM -0700, David Fetter wrote: On Wed, Jul 02, 2008 at 05:57:29PM +0200, Peter Eisentraut wrote: It would also be interesting if EXPLAIN could optionally be a function that returns a datum of type XML, to allow further processing. It would be better to have a function which allows people to plug in their own serialization. A JSON or YAML one, for example, would be much lighter weight on both ends. +1 for either of these. -dg -- David Gould [EMAIL PROTECTED] 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch v2
Peter Eisentraut wrote: Am Mittwoch, 2. Juli 2008 schrieb Tom Raney: This is an update to my EXPLAIN XML patch submitted a few days ago. Could you explain how you came up with the XML schema design? I suppose you just made something up that went along with the existing XML output. Yes, it is based on the existing output. I would like to see more integration with the spirit of the existing XML functionality. For example, instead of things like runtime ms=\%.3f\ /\n we ought to be using XML Schema data types for time intervals and so on. The DTD provides only rudimentary document validation but it has no support for type checking. So, it may make sense to move to the more rigorous XML Schema. There is a 'duration' data type that could be used for the instance listed above. Or, we could define our own. We might also want to use an XML namespace. Taking the 'ms' field listed above: xmlns=http://www.postgresql.org/v8.4/ms; or something like this? Table and index names should be escaped using the existing escape mechanism for identifiers. There might also be encoding issues. That's a good point. Or, wrap them with CDATA. It would also be interesting if EXPLAIN could optionally be a function that returns a datum of type XML, to allow further processing. Any thoughts on these issues? I am in the process of writing a parser of this XML output for the Red Hat Visual Explain tool. I want to see what surprises come up during implementation. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Explain XML patch v2
This is an update to my EXPLAIN XML patch submitted a few days ago. I've added a documentation patch and modified some of the code per comments by Gregory Stark. Because the main consumer of output generated by this patch will presumably be a machine, I didn't clutter up the documentation with matching XML output for every standard example query. But, I added enough to hopefully give the user an idea of what to expect. Regards, Tom Raney *** doc/src/sgml/perform.sgml.orig 2008-07-01 20:27:19.0 -0700 --- doc/src/sgml/perform.sgml 2008-07-01 20:34:44.0 -0700 *** *** 47,59 operations on the raw rows, then there will be additional nodes quoteatop/ the scan nodes to perform these operations. Again, there is usually more than one possible way to do these operations, ! so different node types can appear here too. The output of commandEXPLAIN/command has one line for each node in the plan tree, showing the basic node type plus the cost estimates that the planner made for the execution of that plan node. The first line (topmost node) has the estimated total execution cost for the plan; it is this number that the planner seeks to minimize. /para para Here is a trivial example, just to show what the output looks like. --- 47,62 operations on the raw rows, then there will be additional nodes quoteatop/ the scan nodes to perform these operations. Again, there is usually more than one possible way to do these operations, ! so different node types can appear here too. The standard output of commandEXPLAIN/command has one line for each node in the plan tree, showing the basic node type plus the cost estimates that the planner made for the execution of that plan node. The first line (topmost node) has the estimated total execution cost for the plan; it is this number that the planner seeks to minimize. /para +para +For examples of XML output, see the bottom of this page. +/para para Here is a trivial example, just to show what the output looks like. *** *** 448,453 --- 451,513 process the table in any case, so there's no value in expending additional page reads to look at an index. /para + +para + Examples of XML output: + programlisting + EXPLAIN XML SELECT * FROM tenk1; + +QUERY PLAN + - + ![CDATA[ ?xml version=1.0? + + explain version=x.x + plan name=Seq Scan indent=0 +table name=tenk1/ +cost startup=0.00 total=458.00 rows=1 width=244 / + /plan + /explain + (8 rows)]] + /programlisting + /para + para + programlisting + EXPLAIN ANALYZE XML SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 100 AND t1.unique2 = t2.unique2; + + QUERY PLAN + - + ![CDATA[ ?xml version=1.0? + + explain version=x.x + plan name=Nested Loop indent=0 +cost startup=5.03 total=693.17 rows=100 width=488 / +analyze time_start=0.981 time_end=6.118 rows=100 loops=1 / + /plan + plan name=Bitmap Heap Scan indent=3 +table name=tenk1 alias=t1/ +cost startup=5.03 total=221.07 rows=100 width=244 / +analyze time_start=0.826 time_end=2.226 rows=100 loops=1 / +qualifier type=Recheck Cond value=(unique1 100) / + /plan + plan name=Bitmap Index Scan indent=6 +index name=tenk1_unique1 / +cost startup=0.00 total=5.00 rows=100 width=0 / +analyze time_start=0.663 time_end=0.663 rows=100 loops=1 / +qualifier type=Index Cond value=(unique1 100) / + /plan + plan name=Index Scan indent=3 +index name=tenk2_unique2 / +table name=tenk2 alias=t2/ +cost startup=0.00 total=4.71 rows=1 width=244 / +analyze time_start=0.020 time_end=0.022 rows=1 loops=100 / +qualifier type=Index Cond value=(t2.unique2 = t1.unique2) / + /plan + runtime ms=7.204 / + /explain + (28 rows)]] + /programlisting + /para + /sect1 sect1 id=planner-stats *** doc/src/sgml/ref/explain.sgml.orig 2008-07-01 20:29:14.0 -0700 --- doc/src/sgml/ref/explain.sgml 2008-06-29 20:05:37.0 -0700 *** *** 30,36 refsynopsisdiv synopsis ! EXPLAIN [ ANALYZE ] [ VERBOSE ] replaceable class=parameterstatement/replaceable /synopsis /refsynopsisdiv --- 30,36 refsynopsisdiv synopsis ! EXPLAIN [ ANALYZE ] [ VERBOSE ] [ XML [ DTD ] ] replaceable class=parameterstatement/replaceable /synopsis /refsynopsisdiv *** *** 112,117 --- 112,135 /varlistentry varlistentry + termliteralXML/literal/term + listitem + para + Emit XML output instead of the standard output. + /para + /listitem +/varlistentry + +varlistentry +
[PATCHES] Explain XML patch
*** src/backend/nodes/copyfuncs.c.orig 2008-06-26 18:18:19.0 -0700
--- src/backend/nodes/copyfuncs.c 2008-06-26 07:26:46.0 -0700
***
*** 2568,2573
--- 2568,2575
COPY_NODE_FIELD(query);
COPY_SCALAR_FIELD(verbose);
COPY_SCALAR_FIELD(analyze);
+ COPY_SCALAR_FIELD(xml);
+ COPY_SCALAR_FIELD(dtd);
return newnode;
}
*** src/backend/nodes/equalfuncs.c.orig 2008-06-26 18:18:39.0 -0700
--- src/backend/nodes/equalfuncs.c 2008-06-26 07:25:33.0 -0700
***
*** 1358,1363
--- 1358,1365
COMPARE_NODE_FIELD(query);
COMPARE_SCALAR_FIELD(verbose);
COMPARE_SCALAR_FIELD(analyze);
+ COMPARE_SCALAR_FIELD(xml);
+ COMPARE_SCALAR_FIELD(dtd);
return true;
}
*** src/backend/commands/explain.c.orig 2008-06-10 09:59:12.0 -0700
--- src/backend/commands/explain.c 2008-06-26 15:39:38.0 -0700
***
*** 45,50
--- 45,51
/* options */
boolprintTList; /* print plan targetlists */
boolprintAnalyze; /* print actual times */
+ boolprintXML; /* print output as XML */
/* other states */
PlannedStmt *pstmt; /* top of plan */
List *rtable; /* range table */
***
*** 54,60
const char *queryString,
ParamListInfo params, TupOutputState *tstate);
static void report_triggers(ResultRelInfo *rInfo, bool show_relname,
! StringInfo buf);
static double elapsed_time(instr_time *starttime);
static void explain_outNode(StringInfo str,
Plan *plan, PlanState *planstate,
--- 55,61
const char *queryString,
ParamListInfo params, TupOutputState *tstate);
static void report_triggers(ResultRelInfo *rInfo, bool show_relname,
! StringInfo buf, bool show_xml);
static double elapsed_time(instr_time *starttime);
static void explain_outNode(StringInfo str,
Plan *plan, PlanState *planstate,
***
*** 67,78
StringInfo str, int indent, ExplainState *es);
static void show_upper_qual(List *qual, const char *qlabel, Plan *plan,
StringInfo str, int indent, ExplainState *es);
! static void show_sort_keys(Plan *sortplan, int nkeys, AttrNumber *keycols,
const char *qlabel,
StringInfo str, int indent, ExplainState *es);
- static void show_sort_info(SortState *sortstate,
- StringInfo str, int indent, ExplainState *es);
static const char *explain_get_index_name(Oid indexId);
/*
--- 68,79
StringInfo str, int indent, ExplainState *es);
static void show_upper_qual(List *qual, const char *qlabel, Plan *plan,
StringInfo str, int indent, ExplainState *es);
! static void show_sort_keys(SortState *sortstate, Plan *sortplan, int
nkeys, AttrNumber *keycols,
const char *qlabel,
StringInfo str, int indent, ExplainState *es);
static const char *explain_get_index_name(Oid indexId);
+ static void show_dtd(StringInfo str);
+
/*
***
*** 269,280
es-printTList = stmt-verbose;
es-printAnalyze = stmt-analyze;
es-pstmt = queryDesc-plannedstmt;
es-rtable = queryDesc-plannedstmt-rtable;
initStringInfo(buf);
! explain_outNode(buf,
! queryDesc-plannedstmt-planTree,
queryDesc-planstate,
NULL, 0, es);
/*
--- 270,293
es-printTList = stmt-verbose;
es-printAnalyze = stmt-analyze;
+ es-printXML = stmt-xml;
es-pstmt = queryDesc-plannedstmt;
es-rtable = queryDesc-plannedstmt-rtable;
initStringInfo(buf);
!
! if (stmt-xml) {
! appendStringInfo (buf, ?xml version=\1.0\?\n\n);
!
! /* Only include the DTD if the user *really* wants it */
! if (stmt-dtd)
! show_dtd(buf);
!
! appendStringInfo (buf, explain version=\%s\\n,
PG_VERSION);
! }
!
!
! explain_outNode(buf, queryDesc-plannedstmt-planTree,
queryDesc-planstate,
NULL, 0, es);
/*
***
*** 302,313
show_relname = (numrels 1 || targrels != NIL);
rInfo = queryDesc-estate-es_result_relations;
for (nr = 0; nr numrels; rInfo++, nr++)
! report_triggers(rInfo, show_relname, buf);
foreach(l, targrels)
Re: [PATCHES] Explain XML patch
On Thu, 2008-06-26 at 21:48 -0700, [EMAIL PROTECTED] wrote: *** src/backend/nodes/copyfuncs.c.orig2008-06-26 18:18:19.0 -0700 --- src/backend/nodes/copyfuncs.c 2008-06-26 07:26:46.0 -0700 You probably need to say a whole lot more about this patch. I've updated the wiki with things I've learned while submitting patches. http://wiki.postgresql.org/wiki/Submitting_a_Patch -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch
Simon Riggs [EMAIL PROTECTED] writes: You probably need to say a whole lot more about this patch. I've updated the wiki with things I've learned while submitting patches. http://wiki.postgresql.org/wiki/Submitting_a_Patch Anybody mind if I update that to put more emphasis on the need for documentation? As in documentation patches are *required* if your patch adds or changes user-visible behavior? regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch
Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: You probably need to say a whole lot more about this patch. I've updated the wiki with things I've learned while submitting patches. http://wiki.postgresql.org/wiki/Submitting_a_Patch Anybody mind if I update that to put more emphasis on the need for documentation? As in documentation patches are *required* if your patch adds or changes user-visible behavior? Sure, but I do documentation updates for non-English speakers occasionally. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Explain XML patch
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Anybody mind if I update that to put more emphasis on the need for documentation? As in documentation patches are *required* if your patch adds or changes user-visible behavior? Sure, but I do documentation updates for non-English speakers occasionally. I know that docs from non-native speakers often need heavy editorialization, but that is little excuse for leaving the committer to do *all* the docs work. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
