pgsql/doc/src/sgml Makefile cvs.sgml datatype. ...

Can I ask why a full path of /usr/bin/ was added to collateindex.pl with
no discussion and no mention in the cvs logs? This broke my automatic
build because my binary is in the sgml binary directory. Can it be put
back?

Thanks.

CVSROOT: /cvsroot
Module name: pgsql
Changes by: thomas@postgresql.org 01/12/07 22:24:40

Modified files:
doc/src/sgml : Makefile cvs.sgml datatype.sgml docguide.sgml
installation.sgml syntax.sgml

Log message:
Update list of currently supported platforms.
Mention SQL9x precision syntax for date/time types.
Use PostgreSQL consistantly throughout docs. Before, usage was split evenly
between Postgres and PostgreSQL.

Modified files:
doc/src/sgml/ref: abort.sgml allfiles.sgml alter_group.sgml
alter_table.sgml alter_user.sgml analyze.sgml
begin.sgml close.sgml cluster.sgml
comment.sgml commit.sgml copy.sgml
create_aggregate.sgml create_constraint.sgml
create_database.sgml create_function.sgml
create_group.sgml create_index.sgml
create_language.sgml create_operator.sgml
create_rule.sgml create_sequence.sgml
create_table.sgml create_table_as.sgml
create_trigger.sgml create_type.sgml
create_user.sgml create_view.sgml
createdb.sgml createlang.sgml createuser.sgml
current_time.sgml current_timestamp.sgml
current_user.sgml declare.sgml delete.sgml
drop_aggregate.sgml drop_database.sgml
drop_function.sgml drop_group.sgml
drop_index.sgml drop_language.sgml
drop_operator.sgml drop_rule.sgml
drop_sequence.sgml drop_table.sgml
drop_trigger.sgml drop_type.sgml
drop_user.sgml drop_view.sgml dropdb.sgml
droplang.sgml dropuser.sgml ecpg-ref.sgml
end.sgml explain.sgml fetch.sgml grant.sgml
initdb.sgml initlocation.sgml insert.sgml
ipcclean.sgml listen.sgml lock.sgml move.sgml
notify.sgml pg_ctl-ref.sgml pg_dump.sgml
pg_dumpall.sgml pg_passwd.sgml pg_upgrade.sgml
pgaccess-ref.sgml pgtclsh.sgml pgtksh.sgml
postgres-ref.sgml postmaster.sgml
psql-ref.sgml reindex.sgml reset.sgml
revoke.sgml rollback.sgml select.sgml
select_into.sgml set.sgml set_transaction.sgml
show.sgml truncate.sgml unlisten.sgml
update.sgml vacuum.sgml vacuumdb.sgml

Log message:
Use PostgreSQL consistantly throughout docs. Before, usage was split evenly
between Postgres and PostgreSQL.

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Can I ask why a full path of /usr/bin/ was added to collateindex.pl with
no discussion and no mention in the cvs logs? This broke my automatic
build because my binary is in the sgml binary directory. Can it be put
back?

Well, because it was a mistake on my part ;)

By default, *my* docs build does not work without an altered Makefile,
since the binaries are not found (being located in /usr/bin, not in some
hardcoded directory elsewhere).

That would seem to be an undesirable feature (hardcoding paths to
binaries, wherever they are located). However, I did not intend to
commit that Makefile; it snuck through with the commit of the 50 other
files in that same docs "commitball". Will back out the change (or you
can if you prefer). Of course, no hardcoded paths would be even
better...

- Thomas

(cc'd to -hackers; the topic is my accidentally committing a modified
Makefile, since recovered by Peter E.)

... Of course, no hardcoded paths would be even
better...

It actually is a perl script, not a full-out standalone program. It
seems like we would need this to be a config item or at least capable of
being overridden with Makefile.custom.

Peter, how would you suggest we think about generalizing this?

- Thomas

I understgand the accidental commit problem. Happens to me to at times.

Thanks. That fixed my build. My SGML files or on the web again.

---------------------------------------------------------------------------

Can I ask why a full path of /usr/bin/ was added to collateindex.pl with
no discussion and no mention in the cvs logs? This broke my automatic
build because my binary is in the sgml binary directory. Can it be put
back?

Well, because it was a mistake on my part ;)

By default, *my* docs build does not work without an altered Makefile,
since the binaries are not found (being located in /usr/bin, not in some
hardcoded directory elsewhere).

That would seem to be an undesirable feature (hardcoding paths to
binaries, wherever they are located). However, I did not intend to
commit that Makefile; it snuck through with the commit of the 50 other
files in that same docs "commitball". Will back out the change (or you
can if you prefer). Of course, no hardcoded paths would be even
better...

- Thomas

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thomas Lockhart writes:

... Of course, no hardcoded paths would be even
better...

It actually is a perl script, not a full-out standalone program. It
seems like we would need this to be a config item or at least capable of
being overridden with Makefile.custom.

Probably the latter, by putting ifdef's around the existing assignment.

I like to keep several stylesheet releases around, so I prefer the current
method of referring to the program via the stylesheet distribution's
top-level directory, because it makes it easier to switch everything by
changing a line in Makefile.custom. This is especially important because
there were critical bug fixes in collateindex in the latest stylesheet
release (1.74b, I think), so it's good to know which one you're using
exactly and you probably don't want to use the thing in /usr/bin anyway.

--
Peter Eisentraut peter_e@gmx.net

Probably the latter, by putting ifdef's around the existing assignment.

Should I commit an ifdef'd (actually, ifndef'd) version?

- Thomas