[DOCS] About contrib modules
I'm sorry I haven't said anything yet. I've got no Internet connection at home. I'll work on the remaining work on contrib docs as soon as my Internet connection is restablished. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[DOCS] The translation into Bulgarian
Hello, I am interested in your publication http://www.postgresql.org/docs/8.1/static/kernel-resources.html and would like to translate it to Bulgarian language, so I can share it with the readers on my blog. For doing that I need your written permission. Of course, I will credit you as an author and your webpage as a source. Certainly, I will be grateful if you do the same when I'll be done with translation. The translation is non-commercial and will be posted only on the Web, no print copies are planned. Do you prefer email or IM for contact (if any questions regarding the translation arise)? AIM, MSN, Skype? Regards, Albert Ward - This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. == Unsubscribe [email protected] from this list: http://google.us2.list-manage.com/unsubscribe?u=5210e9ddf3657b393d7f3a010&id=32c5346aed&e=e355b93bf2&c=98e3ecebcd
Re: [DOCS] [HACKERS] Contrib modules documentation online
> > I'm very strongly in favor of having this documentation. However, I think > it might make sense to put "Contrib Modules" as a section under either > "Reference" or "Appendices". Also, I don't think it's necessary to make > each command option a separate subchapter, but I can see how that would be > hard to avoid in an automated system. It's not an automated system, README files have different structures so it's all manual work. That's why I asked how you think it should be organized. Anyone else thinks we should put it in Reference or Appendixes? About command options if done different things, it depends on the module I need to revisit this. I also think one command per subchapter isn't very handy. There's also the install issue. By now it's on the introduction of the chapter. And I've repeated it in some of the modules, not all. Do you think it be better put the exact instructions for compiling and installing for each one? What about 'extra' notes, such us some performance tests, and so one. Some of the notes should probably stay in the README files, just like the README files that can be found in some dirs of core. So I'd keep information targeted to developers into the README's and general info into the main doc. > > Guys, would it be out of the question to do this in 8.3? Please please? I will try to have everything before 8.3. I'd like it gave very little or no work to core developers. If so many people is interested you can help me revise it before the final version. By the way, if somebody has updated any of the contrib README files recently, please send me an e-mail and I'll check if I have the last changes in. -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
[DOCS] Tips needed for contrib doc
Hi, I wanted to spend a week or so putting the contrib doc into shape so I want to start by moving the contrib part from a new appendix to the Reference part. The problems I find are: - I can't make this "contrib" doc a part because Reference already is a part and can't be nested. Structure: - If I make the contrib doc a chapter in the index shows with an arabic number not as a roman one. Structure: - I can't make the doc a because first I need to point to the modules and not all of them are documented like a reference. Structure: - If I leave it as it is now [1] the problem is that very small chapters just don't look right IMHO. Take a look at [2], for example. It should be a module per page in most cases except very long ones. Structure: Does anyone have a solution on this? I'm no docbook expert, so I might be very wrong. [1] You can find the current state at http://www.nan-tic.com/ftp/pgdoc-0.0.2/index.html [2] http://www.nan-tic.com/ftp/pgdoc-0.0.2/adminpack.html -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] Tips needed for contrib doc
The problem with this approach is dblink[1], for example, in which I can't use reference (as I've already used for dblink itself). I will probably have to use in theses cases then... [1] http://www.nan-tic.com/ftp/pgdoc/dblink.html A Dijous 11 Octubre 2007, Tom Lane va escriure: > Guillaume Lelarge <[EMAIL PROTECTED]> writes: > > The only (or simplest) way to have one page per module is to use the > > reference part. > > If the plan is one module per page, why not handle 'em just like the > current command and client reference pages? Add another list to > reference.sgml, and away you go. > > regards, tom lane -- Albert Cervera i Areny http://www.NaN-tic.com ---(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: [DOCS] Tips needed for contrib doc
Not that I want to make each module a reference. With previous discussions we seemed to agree that: - It should go into the References part of the documentation (right after "III. PostgreSQL Server Applications). - Each module docs should be in a single page, mainly because some contrib modules have/require very little documentation. So it seems that the only way of achieving both things is to make each contrib module a inside a new . I don't like this idea, among other things because dblink won't be abe to be treated as a which I think is appropiate in this case. If you've got another solution for this, it'll be very welcome! A Divendres 12 Octubre 2007, Peter Eisentraut va escriure: > Am Mittwoch, 10. Oktober 2007 schrieb Albert Cervera i Areny: > > - I can't make this "contrib" doc a part because Reference > > already is a part and can't be nested. > > The Reference things in DocBook are mostly to support legacy man pages, and > man pages are not necessary the greatest format to document everything. > What is your reason that you want this as a reference rather than a part > with chapters? -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] Tips needed for contrib doc
The problem is that if we want these docs in the Reference section of the documentation right after "PostgreSQL Server Applications" they can't be chapters nor sections, they need to be 's. That's the problem... A Diumenge 14 Octubre 2007, Peter Eisentraut va escriure: > Albert Cervera i Areny wrote: > > Not that I want to make each module a reference. With previous > > discussions we seemed to agree that: > > > > - It should go into the References part of the documentation (right > > after "III. PostgreSQL Server Applications). > > - Each module docs should be in a single page, mainly because some > > contrib modules have/require very little documentation. > > It think you should structure the documentation by content, not by > output format. You could make each module a section or a chapter, as > you choose. -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] Tips needed for contrib doc
A Diumenge 14 Octubre 2007, Peter Eisentraut va escriure: > Albert Cervera i Areny wrote: > > The problem is that if we want these docs in the Reference section of > > the documentation right after "PostgreSQL Server Applications" they > > can't be chapters nor sections, they need to be 's. > > That is not true, AFAICT. What do you base this assertion on? You're right, that's not exactly true: Reference is a Part. If we still want contrib inside Reference, contrib can be a , or other elements defined at http://www.docbook.org/tdg5/en/html/part.html. But I cant' make the contrib section a inside reference (that means no chapter per module!). If I make it a chapter the numbering inside Reference becomes: "I. SQL Commands" "II. PostgreSQL Client Applications" "III. PostgreSQL Server Applications" "43. Standard Modules" Not sure if that's a problem, but that's why I'm asking. That allows, however, having each contrib module in a section in this chapter and thus fits in one page. Though I agree I should concentrate on content, not style, having lots of very small pages isn't very nice either. You can see that in the docs I have online. In that case each module is a chapter as Tom suggests and it's a completely new Part after "Internals" IMHO having it in reference would make sense if contrib docs where organized like, well... references but that's not the case for most of them. After all you need some introduction to the module, some examples, etc. -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] Tips needed for contrib doc
Given some of the problems I exposed earlier and the fact that the documentation of contrib modules isn't organized as a reference. I will be adding a new chapter to the "II. The SQL Language" part probably after "Full Text Search". This will also allow to have each module in one page as desired. Objections? A Dimecres 10 Octubre 2007, Albert Cervera i Areny va escriure: > Hi, > I wanted to spend a week or so putting the contrib doc into shape so I > want to start by moving the contrib part from a new appendix to the > Reference part. -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [DOCS] Placement of contrib modules in SGML documentation
A Diumenge 11 Novembre 2007, Tom Lane va escriure: > I think there's a case for putting these pages under Part V Server > Programming (though a few are not in fact server-side code), or under > Part VI Reference (ignoring the fact that most of the text isn't in a > uniform reference-page style ... though maybe we could plan to work > towards that) or under Appendixes (though I'm sure there are people > who will complain about that because their private agenda is to make > these things as prominent as possible). Or we could make them a new > top-level Part, probably just after Reference. > That's where I put them initialy AFAIR but somebody complained they should be in the Reference. Maybe if we now agree that's not the appropiate place we can move them to a new Part. -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] About contrib modules
A Dijous 22 Novembre 2007, Bruce Momjian va escriure:
> [EMAIL PROTECTED] wrote:
> > I'm sorry I haven't said anything yet. I've got no Internet connection at
> > home. I'll work on the remaining work on contrib docs as soon as my
> > Internet connection is restablished.
>
> Thanks. We probably have 1-2 weeks left to get it into 8.3 final.
Attached, the dict_int and dict_xsyn SGML docs.
Now I'll work on the lost changes of the already SGML'ed docs.
--
Albert Cervera i Areny
http://www.NaN-tic.com
Index: contrib.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/contrib.sgml,v
retrieving revision 1.4
diff -c -r1.4 contrib.sgml
*** contrib.sgml 14 Nov 2007 02:36:43 - 1.4
--- contrib.sgml 2 Dec 2007 17:32:09 -
***
*** 82,87
--- 82,89
&chkpass;
&cube;
&dblink;
+ &dict-int;
+ &dict-xsyn;
&earthdistance;
&fuzzystrmatch;
&hstore;
Index: filelist.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/filelist.sgml,v
retrieving revision 1.53
diff -c -r1.53 filelist.sgml
*** filelist.sgml 14 Nov 2007 01:09:50 - 1.53
--- filelist.sgml 2 Dec 2007 17:32:10 -
***
*** 96,101
--- 96,103
+
+
dict_int
The motivation for this example dictionary is to control the indexing of
integers (signed and unsigned), and, consequently, to minimize the number of
unique words which greatly affect the performance of searching.
Configuration
The dictionary accepts two options:
The MAXLEN parameter specifies the maximum length (number of digits)
allowed in an integer word. The default value is 6.
The REJECTLONG parameter specifies if an overlength integer should be
truncated or ignored. If REJECTLONG=FALSE (default), the dictionary returns
the first MAXLEN digits of the integer. If REJECTLONG=TRUE, the
dictionary treats an overlength integer as a stop word, so that it will
not be indexed.
Usage
mydb# select ts_lexize('intdict', '12345678');
ts_lexize
---
{123456}
Change dictionary options:
mydb# ALTER TEXT SEARCH DICTIONARY intdict (MAXLEN = 4, REJECTLONG = true);
ALTER TEXT SEARCH DICTIONARY
dict_xsyn
The Extended Synonym Dictionary module replaces words with groups of their
synonyms, and so makes it possible to search for a word using any of its
synonyms.
Configuration
It accepts the following options:
KEEPORIG controls whether the original word is included, or only its
synonyms. Default is 'true'.
RULES is the base name of the file containing the list of synonyms.
This file must be in $(prefix)/share/tsearch_data/, and its name must
end in ".rules" (which is not included in the RULES parameter).
The rules file has the following format:
Each line represents a group of synonyms for a single word, which is
given first on the line. Synonyms are separated by whitespace:
word syn1 syn2 syn3
Sharp ('#') sign is a comment delimiter. It may appear at any position
inside the line. The rest of the line will be skipped.
Look at xsyn_sample.rules, which is installed in $(prefix)/share/tsearch_data/,
for an example.
Usage
mydb=# SELECT ts_lexize('xsyn','word');
ts_lexize
{word,syn1,syn2,syn3)
Change dictionary options:
mydb# ALTER TEXT SEARCH DICTIONARY xsyn (KEEPORIG=false);
ALTER TEXT SEARCH DICTIONARY
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [DOCS] About contrib modules
A Dijous 22 Novembre 2007, Bruce Momjian va escriure:
> [EMAIL PROTECTED] wrote:
> > I'm sorry I haven't said anything yet. I've got no Internet connection at
> > home. I'll work on the remaining work on contrib docs as soon as my
> > Internet connection is restablished.
>
> Thanks. We probably have 1-2 weeks left to get it into 8.3 final.
Attached, contrib docs with the changes of the last months. Had to update
cube, apart from most modules of Tom's list. Everything should be up to date
now.
--
Albert Cervera i Areny
http://www.NaN-tic.com
Index: cube.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/cube.sgml,v
retrieving revision 1.2
diff -c -r1.2 cube.sgml
*** cube.sgml 11 Nov 2007 14:23:18 - 1.2
--- cube.sgml 2 Dec 2007 23:32:29 -
***
*** 353,358
--- 353,364
+ cube(text)
+ Takes text input and returns a cube. This is useful for making
+ cubes from computed strings.
+
+
+
cube(float8) returns cube
This makes a one dimensional cube with both coordinates the same.
If the type of the argument is a numeric type other than float8 an
Index: intarray.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/intarray.sgml,v
retrieving revision 1.2
diff -c -r1.2 intarray.sgml
*** intarray.sgml 12 Nov 2007 01:37:34 - 1.2
--- intarray.sgml 2 Dec 2007 23:32:29 -
***
*** 12,20
Current implementation provides index support for one-dimensional array of
! int4's - gist__int_ops, suitable for small and medium size of arrays (used on
default), and gist__intbig_ops for indexing large arrays (we use superimposed
! signature with length of 4096 bits to represent sets).
--- 12,21
Current implementation provides index support for one-dimensional array of
! integers: gist__int_ops, suitable for small and medium size of arrays (used by
default), and gist__intbig_ops for indexing large arrays (we use superimposed
! signature with length of 4096 bits to represent sets). There is also a
! non-default gin__int_ops for GIN indexes on integer arrays.
Index: pageinspect.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/pageinspect.sgml,v
retrieving revision 1.1
diff -c -r1.1 pageinspect.sgml
*** pageinspect.sgml 10 Nov 2007 23:30:46 - 1.1
--- pageinspect.sgml 2 Dec 2007 23:32:29 -
***
*** 32,46
A page image obtained with get_raw_page should be passed as argument:
! test=# SELECT * FROM page_header(get_raw_page('pg_class',0));
!lsn| tli | flags | lower | upper | special | pagesize | version
! --+-+---+---+---+-+--+-
! 0/3C5614 | 1 | 1 | 216 | 256 |8192 | 8192 | 4
! (1 row)
! The returned columns correspond to the fields in the PageHeaderData-struct,
! see src/include/storage/bufpage.h for more details.
--- 32,45
A page image obtained with get_raw_page should be passed as argument:
! regression=# SELECT * FROM page_header(get_raw_page('pg_class',0));
! lsn| tli | flags | lower | upper | special | pagesize | version | prune_xid
! ---+-+---+---+---+-+--+-+---
! 0/24A1B50 | 1 | 1 | 232 | 368 |8192 | 8192 | 4 | 0
! The returned columns correspond to the fields in the PageHeaderData struct.
! See src/include/storage/bufpage.h for more details.
Index: pgbench.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/pgbench.sgml,v
retrieving revision 1.2
diff -c -r1.2 pgbench.sgml
*** pgbench.sgml 11 Nov 2007 14:23:18 - 1.2
--- pgbench.sgml 2 Dec 2007 23:32:29 -
***
*** 379,384
--- 379,399
Variables can also be defined by using -D option.
+
+
+
+ \sleep num [us|ms|s] - Causes script execution to sleep for the
+ specified duration of microseconds (us), milliseconds (ms) or the default
+ seconds (s).
+
+
+ Example:
+
+
+ \setrandom millisec 1000 2500
+ \sleep : millisec ms
+
Index: pgrowlocks.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/pgrowlocks.sgml,v
retrieving revision 1.2
diff -c -r1.2 pgrowlocks.sgml
*** pgrowlocks.sgml 11 Nov 2007 14:23:18 - 1.2
--- pgrowlocks.sgml 2 Dec 2007 23:32:29 -
***
***
Re: [DOCS] About contrib modules
A Dilluns 03 Desembre 2007, Tom Lane va escriure: > Are you planning to do any further work on the contrib docs? I'm I don't have any further work planned by now. Please, go on with the changes.. -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] "distributed checkpoint"
A Dijous 06 Desembre 2007, Alvaro Herrera va escriure: > Am I the only one who finds the phrase "distributed checkpointing" a bit > awkward? Would it be better if we used "time-distributed checkpointing" > instead? > > The phrase is used in the release notes, but it's not used anywhere in > the main docs. To me, non-native english speaker, time-distributed seems the clearer one. -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
