Re: [DOCS] Current CVS docs producing errors
Seems you were caught in mid patch.
They work with cvs sources from 30 minutes ago.
Try updating and re-running -- the last error in particular was caused
by 2 patches crossing in the night (patch queue).
On Tue, 2003-06-24 at 22:52, Bruno Wolff III wrote:
> When building postgres.tar.gz I get the following errors:
>
> make -C sgml clean
> make[1]: Entering directory `/usr/local/src/postgresql-7.4/pgsql/doc/src/sgml'
> rm -f HTML.manifest *.html *.gif
> rm -rf *.1 *.l man1 manl manpage.refs manpage.links manpage.log
> rm -f *.rtf *.tex-ps *.tex-pdf *.dvi *.aux *.log *.ps *.pdf *.out *.eps *.fot
> rm -f HTML.index bookindex.sgml version.sgml features-supported.sgml
> features-unsupported.sgml
> make[1]: Leaving directory `/usr/local/src/postgresql-7.4/pgsql/doc/src/sgml'
> make -C sgml html
> make[1]: Entering directory `/usr/local/src/postgresql-7.4/pgsql/doc/src/sgml'
> /usr/bin/perl /usr/local/share/sgml/stylesheets/docbook/bin/collateindex.pl -f -g -o
> bookindex.sgml -N
> { \
> echo ""; \
> echo " '\([0-9][0-9]*\.[0-9][0-9]*\)'`\">"; \
> } >version.sgml
> /usr/bin/perl ./mk_feature_tables.pl YES
> ../../../src/backend/catalog/sql_feature_packages.txt
> ../../../src/backend/catalog/sql_features.txt > features-supported.sgml
> /usr/bin/perl ./mk_feature_tables.pl NO
> ../../../src/backend/catalog/sql_feature_packages.txt
> ../../../src/backend/catalog/sql_features.txt > features-unsupported.sgml
> openjade -V draft-mode -D . -c /usr/local/share/sgml/stylesheets/docbook/catalog -d
> stylesheet.dsl -i output-html -t sgml postgres.sgml
> openjade:datatype.sgml:2611:12:E: document type does not allow element "ROW" here
> openjade:datatype.sgml:2616:12:E: document type does not allow element "ROW" here
> openjade:datatype.sgml:2621:5:E: document type does not allow element "ROW" here
> openjade:datatype.sgml:2625:5:E: document type does not allow element "ROW" here
> openjade:datatype.sgml:2629:14:E: end tag for "ROW" omitted, but OMITTAG NO was
> specified
> openjade:datatype.sgml:2625:1: start tag was here
> openjade:datatype.sgml:2629:14:E: end tag for "ROW" omitted, but OMITTAG NO was
> specified
> openjade:datatype.sgml:2621:1: start tag was here
> openjade:datatype.sgml:2629:14:E: end tag for "ROW" omitted, but OMITTAG NO was
> specified
> openjade:datatype.sgml:2607:1: start tag was here
> openjade:perform.sgml:69:19:X: reference to non-existent ID
> "RUNTIME-CONFIG-OPTIMIZER"
> openjade:/usr/local/share/sgml/stylesheets/docbook/html/../common/dbtable.dsl:224:13:E:
> 2nd argument for primitive "ancestor" of wrong type: "#"
> not a singleton node list
> openjade:/usr/local/share/sgml/stylesheets/docbook/html/dblink.dsl:203:1:E: XRef
> LinkEnd to missing ID 'RUNTIME-CONFIG-OPTIMIZER'
> make[1]: *** [html] Error 1
> make[1]: Leaving directory `/usr/local/src/postgresql-7.4/pgsql/doc/src/sgml'
> make: *** [postgres.tar] Error 2
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faqs/FAQ.html
--
Rod Taylor <[EMAIL PROTECTED]>
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
Description: This is a digitally signed message part
Re: [DOCS] Current CVS docs producing errors
On Tue, 2003-06-24 at 23:18, Bruno Wolff III wrote: > On Tue, Jun 24, 2003 at 22:52:32 -0400, > Rod Taylor <[EMAIL PROTECTED]> wrote: > > Seems you were caught in mid patch. > > > > They work with cvs sources from 30 minutes ago. > > > > Try updating and re-running -- the last error in particular was caused > > by 2 patches crossing in the night (patch queue). > > I resynced and picked up a new perform.sgml and TODO.sgml. This got rid > of one of the errors. I am still seeing all of the datatype.sgml errors. > I wasn't getting these errors a couple of days ago. Are you sure you don't have local changes? A conflict perhaps? Try removing datatype.sgml and re-fetching it again. Below is the only change to that file in a number of days, and it looks fine to me. http://developer.postgresql.org/cvsweb.cgi/pgsql-server/doc/src/sgml/datatype.sgml.diff?r1=1.117&r2=1.118 -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [DOCS] Mysql -> Postgresql pitfalls
> speak in the \copy command. I.e. you wouldn't use inserts to load your > data, you'd use a bulk copy, which bypassess all the serial / IDENTITY > stuff. Basically, with the IDENTITY type, if you try to insert a value, COPY enforces everything that insert does. It's simply a little quicker than insert due to a different string parsing method and avoiding places that are for advanced features (subselects, functions, etc.). A default is still applied if the column has not been provided. Likewise, triggers (constraint triggers anyway) still run. Bumping the start value for an IDENTITY is simple: CREATE TABLE tab ( col integer GENERATED ALWAYS AS IDENTITY(START WITH 42) ); I suppose we'll need a GUC so that GENERATED ALWAYS isn't actually always -- just usually. signature.asc Description: This is a digitally signed message part
Re: [DOCS] Need help with SGML again
> > Any thoughts on replacing Docbook with something else, someday? > > I don't see anything better arising. Neither do I, but our particular use of docbook is far from the easiest to work with. There are many tools which can give a nicer working environment for editing docbook based documents, but I've yet to find one which fits in with the PostgreSQL configuration. Perhaps you could suggest a toolset which can work with our docs and hide the syntax from the user and give a 1st approximation of what the final document would look like (without installing tons of tools -- many of which are difficult to find in non-unix environments). This would be much appreciated. Recently, I've been using Openoffice for a first cut and Conglomerate to clean the document up. Of course, that uses a strict XML version and I normally prefer xincludes to entity based includes. With xincludes, each document is valid individually, as such can be rendered individually. You don't need to process the full book to see what the 2 new paragraphs in section N.n will look like. Throw an XML transform at the top for Internet Explorer and you don't need any tools outside the text editor, webbrowser, and diff. signature.asc Description: This is a digitally signed message part
Re: [DOCS] Need help with SGML again
On Wed, 2003-10-15 at 12:29, Peter Eisentraut wrote: > Rod Taylor writes: > > > Recently, I've been using Openoffice for a first cut and Conglomerate to > > clean the document up. Of course, that uses a strict XML version and I > > normally prefer xincludes to entity based includes. > > If you can find/propose/develop an XML-based setup that has the same > functionality as our current setup, I wouldn't mind switching. Some > things that I see as requirements are: > > 1. Does the HTML output look at least as good as the current output? (The > default DocBook XSLT stylesheets do not, AFAIR.) > > 2. Is there a toolchain that can create PDFs, that actually work on our > input files? (FOP does not, AFAIR; PassiveTeX is a pain to set up.) You don't need to switch toolkits to use XML input files as the source. Openjade and friends all support XML with the exception of xincludes (frankly, they're the best part). A single XML document can be generated out of several from xincluded source with a xsltproc which is then fed that into openjade. As far as the HTML goes, the Gnome & FreeBSD documentation teams have put some work into making the HTML come out right -- some things come out much better (media items). Print is still lacking, but stated above we can still use the old toolchain for that. Is this something that is worth investigating? I'm happy to do the work, but my process in submitting documentation changes has been lacking (as shown by non-acceptance). What would you like as proof of concept for buy in prior to converting the entire toolchain? signature.asc Description: This is a digitally signed message part
Re: [DOCS] Need help with SGML again
On Wed, 2003-10-15 at 13:58, Peter Eisentraut wrote: > Rod Taylor writes: > > > You don't need to switch toolkits to use XML input files as the source. > > Openjade and friends all support XML with the exception of xincludes > > (frankly, they're the best part). > > But the xincludes part kind of invalidates your point, no? If we just > switch to XML and keep using OpenJade, then we're not really gaining much, You didn't read the rest. We do implement and use xincludes in the source files for the various interfaces to edit with, webbrowser to to transforms on, etc. We simply add an xsltproc step prior to OpenJade processing to create a single document for OpenJade to deal with, rather than forcing OpenJade to pull parts of documents in via xincludes or system entities. This will give us the exact same output as prior, but will enable people such as Josh to edit the docs without panicking (part of the solution is a recommended toolkit). signature.asc Description: This is a digitally signed message part
Re: [DOCS] The Tutorial(TM)
On Thu, 2004-01-08 at 12:07, Peter Eisentraut wrote: > David Fetter wrote: > > Expanding on that, putting FK's in "Advanced Features" gives the (IME > > always wrong) impression that they're optional. > > They *are* optional. > > The first chapter is about getting the data in and out. That is not > optional for using a database. Transactions, views, foreign keys, > primary keys even, and everything else that some people think is > essential for a "real" database are in fact optional. Remember that > the tutorial is intended for people starting from zero. Let's not > overwhelm them right away. Perhaps it's simply the wrong title. "Design" in place of "Advanced Features" They're not advanced database features, but they aren't required learning until you're designing the environment rather than simply using the environment. ---(end of broadcast)--- TIP 3: 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: [DOCS] Suggestion on reorganizing functions
On Mon, 2004-08-09 at 16:39, Tom Lane wrote: > Jeff <[EMAIL PROTECTED]> writes: > > One idea to solve it would to have the flat list link to > > functions-foo.html#FOOBAR - this would allow both methods of > > organization and only having function definitions in one spot. > > Basically what you're proposing is an index. > > I am not sure if DocBook could handle generating an index covering just > functions, or if we'd have to merge it with the general index. If the > latter then it's pretty much done already. (We may have missed indexing > some function descriptions, but certainly a lot of them have an index entry.) If we were using XML based docbook we could use an xmlinclude to generate this type of content on the fly during output generation. The big snag is that XML Docbook does not produce very nice printable documents without a rather expensive toolkit. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
