[DOCS] The supplementary proposal of pg_ctl reload
Hi. There is the following description in [17.1. Setting Parameters]. http://www.postgresql.org/docs/8.1/interactive/runtime-config.html#CONFIG-SETTING > The configuration file is reread whenever the postmaster process receives > a SIGHUP signal When I tried 'pg_ctl reload' with some lines commented out, I found that the value for the commented-out parameter was staying unchanged, rather than set to the default value. For example, "log_min_duration_statement" The default is set as -1 and commented out in postgresql.conf. If I tried it to set 0 and 'reload', parameter will set to 0 at postmaster. but I want changed to -1 at postmaster, tried it commented-out in postgresql.conf and reload, it will still unchanged. it can chenge by 'restart'. I think that it should supplement since it is easy to misunderstand this specification. Because, at 'pg_ctl start' and 'pg_ctl reload', treatment of the line which commented out at the time of reading postgresql.conf looks differ, cautions are required. Therefore, I think that it should supplement. I'd like to propose to add the following to the above "A second way to set there configuration parameters": --- When parameters in postgresql.conf are commented out and reloaded, those values will not be changed to the default values and will stay at the present states. --- (Somebody of native English speakers check this text...) Regards, Katsuhiko Okano okano katsuhiko _at_ oss ntt co jp ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [DOCS] New XML section for documentation
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes: > On 8/26/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote: >> "Valid" and "well-formed" have very specific distinct meanings in XML. >> (Note that "check" doesn't have any meaning there.) We will eventually >> want a method to verify both the validity and the well-formedness. >> >> I think that a function called xml_valid checks for well-formedness is >> an outright bug and needs to be fixed. > That's exactly what I'm talking about. xml_valid() is wrong name and > it may confuse people. > Bruce suggested to use overload to keep backward compat. - in other > words, 1-arg function for checking for well-formedness and 2-arg > function for validation process. That's bad too: ISTM the right answer is to add xml_is_well_formed() in this release and have xml_valid as an alias for it, with documentation explaining that xml_valid is deprecated and will be removed in the next release. Then we can add a proper validity-checking function too. Nikolay submitted a patch later http://archives.postgresql.org/pgsql-patches/2006-09/msg00123.php that does part of this and can easily be adapted to add the alias. His patch also adds an xpath_array() function --- what do people think about that? It's well past feature freeze ... now we've always been laxer about contrib than the core code, but still I'm inclined to say that that function should wait for 8.3. Comments? It's time to get a move on with resolving this. 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
[DOCS] Proposal for documenting 8.2 VALUES syntax
I spent a bit of time thinking about the best way to document 8.2's more powerful VALUES clause. Here's the plan I came up with: * There needs to be some introductory material in Part II, and the only place it seems to fit at all is under Chapter 7, Queries. I think there should be a new page covering VALUES. We could add it at the end of the chapter (ie, a new section 7.7) or we could insert it between sections 7.3 Select Lists and 7.4 Combining Queries. The argument for the latter position is that VALUES is now syntactically parallel to SELECT, and so you can use it as if it were SELECT in UNION/INTERSECT/ EXCEPT structures as described in 7.4, as well as attach the ORDER BY, LIMIT, OFFSET clauses described in 7.5 and 7.6. However that might be putting too much emphasis on syntactic form as opposed to pedagogical clarity. I'm a bit inclined to put it at the end of the chapter and then explain "by the way, you can also attach that other stuff to it". Thoughts? * The SELECT reference page is huge already, so I would rather add only the minimum possible amount to it. This leads to the conclusion that we'd better create a new ref/ entry just for VALUES. I think that's appropriate anyway, since there is some material that doesn't seem like it would fit anywhere else --- in particular, that we want to warn off people from expecting umpteen-billion-row VALUES constructs to work well. * Joe's original draft docs patch added examples to the INSERT, UPDATE, DELETE, etc reference pages. While we obviously have got to update the INSERT page, I'm inclined to use the rest of that material in the new VALUES reference page. Comments? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] Proposal for documenting 8.2 VALUES syntax
Tom Lane wrote: > I spent a bit of time thinking about the best way to document 8.2's more > powerful VALUES clause. Here's the plan I came up with: > > * There needs to be some introductory material in Part II, and the only > place it seems to fit at all is under Chapter 7, Queries. I think there > should be a new page covering VALUES. We could add it at the > end of the chapter (ie, a new section 7.7) or we could insert it between > sections 7.3 Select Lists and 7.4 Combining Queries. The argument for > the latter position is that VALUES is now syntactically parallel to > SELECT, and so you can use it as if it were SELECT in UNION/INTERSECT/ > EXCEPT structures as described in 7.4, as well as attach the ORDER BY, > LIMIT, OFFSET clauses described in 7.5 and 7.6. However that might be > putting too much emphasis on syntactic form as opposed to pedagogical > clarity. I'm a bit inclined to put it at the end of the chapter and > then explain "by the way, you can also attach that other stuff to it". > Thoughts? I agree with putting it at the end of the chapter. > * The SELECT reference page is huge already, so I would rather add only > the minimum possible amount to it. This leads to the conclusion that > we'd better create a new ref/ entry just for VALUES. I think that's > appropriate anyway, since there is some material that doesn't seem like > it would fit anywhere else --- in particular, that we want to warn off > people from expecting umpteen-billion-row VALUES constructs to work > well. I agree here as well. One likely useful example, if not already covered, is select ... FROM ... WHERE op ANY (VALUES ( ... )) I tripped over it a couple of days ago and it seems useful and non obvious. ISTM it beats the current practice of op ANY(ARRAY[ ... ]) which seems a bit of a kludge. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] Proposal for documenting 8.2 VALUES syntax
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> ... One likely useful example, if not already covered, is
> select ... FROM ... WHERE op ANY (VALUES ( ... ))
> I tripped over it a couple of days ago and it seems useful and non
> obvious. ISTM it beats the current practice of
> op ANY(ARRAY[ ... ])
> which seems a bit of a kludge.
Unfortunately, we don't optimize the former nearly as well as the latter
:-(. I was thinking of showing an example of a multi-column IN:
where (firstname,lastname) in (values ('joe','blow'), ('anne','smith'), ...
but I don't think we want to encourage people to use it in cases where
a scalar list or ANY(ARRAY) will serve. Maybe next year ;-)
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
