This patch makes two minor fixes to the docs: (1) fixes a
spelling mistake in the PREPARE ref page (2) Makes some
English more consistent, in the ref pages for some of the
client apps (3) Adds a link to the libpq docs in the
vacuumdb ref page.
-Neil
Index: doc/src/sgml/ref/clusterdb.sgml
Minor SGML gripes...
On Fri, Aug 22, 2003 at 10:00:00AM -0400, Andrew Dunstan wrote:
! To avoid this situation, run postgres on a machine where you
postgres should be productnamePostgreSQL/productname.
! altering the system's default behaviour. This can be determined
! by
This patch makes a number of improvements to the runtime config
documentation.
-Neil
Index: doc/src/sgml/runtime.sgml
===
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.201
diff -c -r1.201
This patch fixes a trivial typo in the CREATE FUNCTION ref page.
-Neil
Index: doc/src/sgml/ref/create_function.sgml
===
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ref/create_function.sgml,v
retrieving revision 1.49
diff -c
On Fri, 2003-09-05 at 17:16, Peter Eisentraut wrote:
Currently, the documentation contains about 2 GUC variable names in upper
case, the rest is lower case.
There are significantly more than 2 uses of upper-case GUC names in the
docs (more like 10 by my guess), but in any case, the current
On Mon, 2003-09-08 at 11:09, Gaetano Mendola wrote:
Tom Lane [EMAIL PROTECTED] wrote:
I see no value at all in an assert. The code will dump core just fine
with or without an assert ...
Right but an assert can display information about the file and line number
without debug the
On Thu, 2003-09-11 at 11:58, Bruce Momjian wrote:
Uh, how do you force the stats collector to 'on' before the test is
run?
The stats collector is on by default (of course, that doesn't apply to
make installcheck...)
But this reminds me: I think it would be cool to extend the language we
use
This patch makes a few incremental improvements to geqo.sgml and
arch-dev.sgml
-Neil
Index: doc/src/sgml/arch-dev.sgml
===
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/arch-dev.sgml,v
retrieving revision 2.21
diff -c -r2.21
This patch fixes an obvious bug in the should I print the duration of
this query? logic in postgres.c
I also don't particularly like the format of the log message (for one
thing, the duration_statement prefix in the log message shouldn't
include an underscore, it's not a variable or anything --
This patch adds a new GUC var, default_use_oids, which follows the
proposal for eventually deprecating OIDs on user tables that I posted
earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or
WITHOUT OIDS when dumping a table. The documentation has been updated.
Comments are welcome.
On Sun, 2003-10-05 at 19:58, Tom Lane wrote:
That's a fairly useless place to put it, though, since someone would
only think to look at sort_mem if they already had a clue. It should
be mentioned under bulk data load (in performance tips chapter)
Attached is a doc patch that does this. The
On Tue, 2003-10-14 at 15:00, Manfred Spraul wrote:
I think we must either add -fno-strict-aliasing, or switch to the c
compiler memset functions for gcc.
The last time we did some benchmarking, using the builtin memset()
imposes a significant performance penalty on plenty of different
On Tue, 2003-10-14 at 16:29, Peter Eisentraut wrote:
The last time I did some testing, the builtin memset() was significantly
faster on plenty of different platforms.
Oh? Which platforms are you referring to, and what tests were performed?
You can find the benchmark results I'm referring to in
This patch adds another item to the migration to 7.4 list in the
HISTORY file, and attributes the shared-buffer-alignment change to
Manfred Spraul.
-Neil
Index: HISTORY
===
RCS file: /var/lib/cvs/pgsql-server/HISTORY,v
retrieving
On Fri, 2003-10-10 at 05:56, Manfred Koizar wrote:
On Tue, 30 Sep 2003 20:00:22 -0400, Neil Conway [EMAIL PROTECTED]
wrote:
This patch adds a new GUC var, default_use_oids
Shouldn't it be honoured by CREATE TABLE AS SELECT ... ?
Good catch. I've attached an updated patch. I also included
This patch reduces some unsightly #ifdefs, and fixes two typos in
comments in the psql code. This doesn't make any functional change, so
feel free to save it for 7.5
-Neil
Index: src/bin/psql/command.c
===
RCS file:
This patch makes a bunch of improvements to the release notes. I only
modified release.sgml -- HISTORY will need to be regenerated.
I was able to remove almost all of the Other uncategorized release
note entries, but left a few that I wasn't sure what to do with. We
should remove this section,
On Sun, 2003-10-26 at 00:50, Bruce Momjian wrote:
listitemparaMake MOVE/FETCH 0 now does nothing
(Bruce)/para/listitem
Still wrong :-) Make ... now does nothing is ungrammatical.
The other modified entry is incorrect for the same reason (Cause ...
now returns).
-Neil
This patch cleans up some of the bufmgr code:
- replace uses of
LockBuffer(buf, BUFFER_LOCK_UNLOCK);
ReleaseBuffer(buf);
with the equivalent, but more concise:
UnlockAndReleaseBuffer(buf);
- analogous changes were made by replacing LockBuffer() +
Currently, equal() does the following for List nodes:
case T_List:
{
List *la = (List *) a;
List *lb = (List *) b;
List *l;
/*
* Try to reject by length check before we grovel through
* all the elements...
*/
if
On Mon, 2003-11-03 at 10:04, Tom Lane wrote:
You have effectively reverted the code to its previous slow state.
Erm, the original version of this code in CVS (from ~7 years ago) is the
following:
case T_List:
{
List *la = (List*)a;
List *lb = (List*)b;
On Mon, 2003-11-03 at 10:00, Tom Lane wrote:
I do not actually agree with the UnlockAndReleaseBuffer changes
anyway. I think this obscures the code by making resource grabbing
and resource releasing code unsymmetrical
Hmm... fair enough, I see your point. In that case, should I remove the
Ok, I've attached new versions of list.c and pg_list.h -- this is just a
*rough sketch* of the new List code -- it definitely won't compile, the
intent is just to concretely specify the new List design. Also, I've
only updated the important list functions: I stopped at nth().
(I've attached the
Gaetano Mendola [EMAIL PROTECTED] writes:
Why instead of reinvent the whell not use, or at least do a C port of
stl::list ?
Because (a) implementing a linked list is pretty trivial (b) the only
difficult part is getting the semantics / API right. I don't see how
std::list would help with (b),
Tom Lane [EMAIL PROTECTED] writes:
This does suggest that it might be worth making the struct layout be
int NodeTag;
int length;
foo *head;
foo *tail;
since this would avoid some padding overhead on a machine where pointers
are 8 bytes and need 8-byte alignment.
Rod Taylor [EMAIL PROTECTED] writes:
In src/backend/utils/adt/inet_net_ntop.c and
src/backend/utils/adt/inet_net_pton.c it would appear that the $Id$ tag
is assigned to a variable (rcsid).
... which is never referenced AFAICT, even if the necessary
preprocessor definitions are set so that it
Gaetano Mendola [EMAIL PROTECTED] writes:
10E6 INSERT = real 0m5.161s
user 0m4.010s
sys0m1.150s
What operation is this benchmarking? Only linked-list appends, or
something else?
-Neil
---(end of
Bruce Momjian [EMAIL PROTECTED] writes:
I have grabbed code from NetBSD before, and I just mention that fact at
the top of the file. There is no need to repeat their license as it is
the same as our license.
src/port/qsort.c is wrong, then: (a) it includes the full NetBSD
copyright/warranty
Bruce Momjian [EMAIL PROTECTED] writes:
I don't change the copyright, but I think we can take the copyright
of the project rather than those of the individual files.
So can we remove the offending license clauses, then?
Also, it's worth noting that the license in 'COPYRIGHT' is not exactly
the
This patch refactors execTuples.c in two ways:
(1) ExecInitXXXResultTupleSlot() used a macro to avoid some
duplicated code, whereas calling ExecInitExtraTupleSlot() would
make the code more clear.
(2) ExecTypeFromTL() and ExecCleanTypeFromTL() duplicated a bunch
Hans-Jürgen Schönig [EMAIL PROTECTED] writes:
I have attaches a patch against 7.4.0 which contains the
implementation of the following todo item.
I sent a proposal for this functionality to -hackers a month or so
ago, and implemented it a couple days later -- it was sent to
pgsql-patches, and
This patch fixes a trivial compiler warning introduced recently in
bufmgr.c
-Neil
Index: src/backend/storage/buffer/bufmgr.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/storage/buffer/bufmgr.c,v
retrieving revision 1.145
diff
Tom Lane [EMAIL PROTECTED] writes:
I think this is taking the avoid duplicated code mantra a little
far. You've defined a subroutine that returns a TupleDesc that is
internally inconsistent and cannot usefully be used for anything
until it's fixed by the parent routines.
Fair enough. Another
Tom Lane [EMAIL PROTECTED] writes:
That would be okay with me. It might be a good idea to change the
name completely (perhaps CopyTupleDesc() ?) as a means of catching
places that aren't correctly updated.
Done, and done -- a revised patch is attached.
-Neil
Index:
There is an unused variable in an example function in the PL/PgSQL
documentation; this patch removes it.
-Neil
Index: doc/src/sgml/plpgsql.sgml
===
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/plpgsql.sgml,v
retrieving revision
Bruce Momjian [EMAIL PROTECTED] writes:
I am going to try to fill the queue tonight and apply it Monday. I
leave for Japan on Tuesday.
Applying a load of patches and then promptly fleeing the country
doesn't sound so wise -- it sounds mighty suspicious, in fact :-)
(At the same time, I can
Bruce Momjian [EMAIL PROTECTED] writes:
We need a solution to this.
I'm really not sure we do: the SQL produced by pg_dump was totally
non-portable before, and it is slightly less portable now. ISTM that
you will almost always need to do some post-processing of pg_dump's
output to have any hope
Bruce Momjian [EMAIL PROTECTED] writes:
I assume this patch is to control this way of breaking out of a
read-only transaction:
[...]
This seems like a valuable feature, as others have mentioned.
Why is this feature valuable?
A read only user is still able to easily DOS the server, consume
Peter Eisentraut [EMAIL PROTECTED] writes:
I'm sure there are other ways to phase out OIDs in dumps.
Okay, fair enough -- I'll submit a patch to change this.
-Neil
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
A GUC variable in runtime.sgml had the wrong markup -- this patch
fixes that, and makes a few other tiny SGML improvements.
-Neil
Index: doc/src/sgml/runtime.sgml
===
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v
This patch makes some editorial improvements to the bug reporting
guidelines and the LOCK reference page.
-Neil
Index: doc/src/sgml/problems.sgml
===
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/problems.sgml,v
retrieving
This patch makes some improvements and adds some details to the
documentation on routine database maintenance activities. Any comments
on the new text would be appreciated. I decided not to mention the
FSM -- I haven't seen any reports that users have had to tweak FSM
settings in 7.4, and it is
The wal_debug GUC variable was of type integer, but it was used in
the code effectively as a boolean: the code only tested whether it was
zero or non-zero. This patch makes it a proper boolean.
-Neil
Index: doc/src/sgml/runtime.sgml
Peter Eisentraut [EMAIL PROTECTED] writes:
Looks good, but did you have a specific reason to prefer LOCK TABLE over
plain LOCK?
None other than consistency: the majority of the usages in lock.sgml
already used LOCK TABLE, so I converted the rest over. I don't
particularly prefer one form over
Tom Lane [EMAIL PROTECTED] writes:
I agree. Having a special debug variable for WAL seems like a
short-term thing whose time has passed.
ISTM that there is little distinguishing wal_debug and the following
GUC vars:
log_btree_build_stats
trace_notify
trace_locks
trace_userlocks
trace_lwlocks
Peter Eisentraut [EMAIL PROTECTED] writes:
It's kind of hard to see what you have really changed. Can you
provide a summary?
The majority of the changes are in the 3rd patch hunk; ISTM it is
pretty easy to see what has been changed. I spent more time discussing
the differences between VACUUM
Tom Lane [EMAIL PROTECTED] writes:
The others are already #ifdef'd out by default, which is more or
less what I was suggesting you do with the wal_debug code.
(FWIW, trace_notify is not #ifdef'd out.)
But I thought that you (and Peter) were suggesting that this shouldn't
be made a GUC variable
This patch fixes a few more uppercase GUC vars. I also removed an
example from the RESET reference page because it seemed completely
redundant.
-Neil
Index: doc/src/sgml/ref/analyze.sgml
===
RCS file:
Neil Conway [EMAIL PROTECTED] writes:
This patch makes some SGML markup more consistent and makes a small
improvement to the SSL auth docs.
Patch applied to HEAD.
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go
Neil Conway [EMAIL PROTECTED] writes:
This patch makes some editorial improvements to the bug reporting
guidelines and the LOCK reference page.
Patch applied to HEAD.
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet
Neil Conway [EMAIL PROTECTED] writes:
I've attached a revised patch that incorporates these
changes. Thanks for the feedback!
Patch applied to HEAD. Thanks again, Robert Peter.
-Neil
---(end of broadcast)---
TIP 4: Don't 'kill -9
Bruce Momjian [EMAIL PROTECTED] writes:
Let me add that Claudio is doing a fantastic job on this. The
changes are minimal and clean. I think the writing of a per-backend
temp file has allowed this patch to be smaller than it might have
been.
Did we REALLY conclude that the best way to work
Bruce Momjian [EMAIL PROTECTED] writes:
I don't think we ever discussed it, but it seemed logical and a minimal
change to the code. We already have a GUC write of non-default values
for exec and no one had issues with that.
For the record, I think that is ugly as well :-)
Anyway, I'm not
Claudio Natoli [EMAIL PROTECTED] writes:
This patch is the next step towards (re)allowing fork/exec.
I've included a few comments on the patch below. Unfortunately I only
had time to briefly look over the code...
Why did you change ShmemIndexLock from an LWLock to a spinlock?
The number of
Tom Lane [EMAIL PROTECTED] writes:
That one I can answer --- it's a bootstrapping issue: we can't use
LWLocks until we have a PGProc (*MyProc), and we can't set that up
without looking in the ShmemIndex for the related data structures.
So ShmemIndex needs to use a more primitive lock type.
This patch removes the following unused typedefs from c.h:
bool8, bool16, bool32, word8, word16, word32, Offset
In order to remove Offset I had to update some code in
page/bufpage.c, but that shouldn't have been using Offset to begin
with, AFAICS.
Unless anyone complains, I'll apply this
This patch removes the remaining code for processing the '-C'
command-line option in the standalone backend. It no longer actually
functions (i.e. specifying the option does nothing), and I didn't
think it was interesting enough to be worth reviving, so I removed it.
Unless anyone objects, I
In any modern dialect of C, casting the NULL pointer literal to a
specific pointer type is unnecessary. For example:
char *foo;
foo = malloc(...);
if (foo == (char *) NULL) {...}
The cast on the 3rd line serves no useful purpose. Hence, this patch
removes all such instances of
This patch cleans up some code in the smgr and elsewhere:
- Update comment in IsReservedName() to the present day, remove
ugly coding for speed as this is no longer a performance
critical function
- Improve some variable function names in commands/vacuum.c. I
was
Tom Lane [EMAIL PROTECTED] writes:
BTW, I was planning to ask you where that stood. I've been writing
new code on the assumption that I didn't have to bother with
FastList
Yeah, I definitely plan to have the list rewrite finished in time for
7.5. After the bufmgr work, it's the next thing on
Neil Conway [EMAIL PROTECTED] writes:
Unless anyone objects, I intend to apply this in 24 hours or so.
Patch applied.
-Neil
P.S. BTW, how does everyone feel about the methodology I've been using
for submitting and applying patches? The procedure I'm following is:
- for trivial / obviously
Tom Lane [EMAIL PROTECTED] writes:
This change is actually wrong (backwards), no? You want a true result
on equality.
*sigh*, I'm an idiot. Thanks for catching my mistake!
Pretending that the result of strcmp is a bool is a type pun, and
one that can rise up to bite you. In the case at
This patch separates the 'Value' and 'List' nodes: now the Value node
has its own interface (i.e. header) and implementation files. This is
just house-keeping, in preparation for the list rewrite.
I renumbered a NodeTag: does that require a catalog version number
bump?
Unless anyone objects, I
This patch adds a WITH / WITHOUT OIDS clause to CREATE TABLE
AS. This allows the user to explicitly specify whether OIDs should be
included in the newly-created relation (if form of this clause is
specified, the default_with_oids configuration variable is used). This
is useful because it provides
Bruce Momjian [EMAIL PROTECTED] writes:
Does this deal with the fact we now emit WITH/WITHOUT OID in
pg_dump?
No, that is an unrelated issue. I took a brief look at implementing
this over the break, but I couldn't see an easy way to do it properly:
if we pick a particular default for the GUC
Tom Lane [EMAIL PROTECTED] writes:
This is just cleanup, right?
Right -- AFAICS, there is no reason for the two nodes to be in the
same file.
Or were you intending that something will happen to Value in
connection with the List changes? I can't think what offhand ...
Neither can I -- ISTM
Bruce Momjian [EMAIL PROTECTED] writes:
Couldn't we use SET only when we need to change the existing value?
I'm not sure what you mean. The pg_dump output will look like:
-- at the top of the dump
SET default_with_oids = false; -- or true, doesn't really matter
-- for a table that doesn't have
Tom Lane [EMAIL PROTECTED] writes:
One thing that is *not* fine is something that I see had snuck past
me in the previous WITH OIDS patch. It is not okay for gram.y or
scan.l to be looking at GUC variables --- that creates
synchronization issues.
Good point (I remember reading gram.y's
Bill Moran [EMAIL PROTECTED] writes:
Neil Conway wrote:
- don't use C++-style comments
Oops ... sorry ... been doing too much PHP.
BTW: Why is this frowned apon so? Are there compilers that have
problems with it?
IMHO it's not so much that it's considered THAT evil, it's just an
easy
This patch fixes a bug I introduced in the recent CREATE TABLE AS / WITH
OIDS work. The patch should be pretty straight-forward.
The only question I have is whether analyze.c (and therefore
analyze.h) is the right place to put the new utility function
interpretOidsOption() -- can anyone suggest a
Tom Lane [EMAIL PROTECTED] writes:
You could possibly put it next to the existing function
interpretInhOption(), which does essentially the same kind of thing
and for the same reason. However, I can't argue that that
function's placement in parse_clause.c has any real strong
motivation
This patch makes some of the memory manipulation performed by psql a
little more sane. Some parts of the code was using a static function
xmalloc() that did safe memory allocation (where safe means bail
out on OOM), but most of it was just invoking calloc() or malloc()
directly. So I moved
This patch replaces a bunch of call sites of appendStringInfo() with
appendStringInfoString(). (For those without the code in front of
you, the difference between these two functions is that the former
takes a sprintf-style format string and a variable list of arguments,
whereas the latter just
I've attached the latest header and implementation files (pg_list.h
and list.c, respectively) for the new linked list implementation. I'm
pretty satisfied with the new API: now would be the ideal time to
suggest any changes you think I should make to it. I decided to use a
new naming convention:
Gavin Sherry [EMAIL PROTECTED] writes:
The attached patch clarifies (or, rather, makes explicit) to readers how
to handle memory management for char pointers returned by libpq
functions.
Patch applied. I expanded the tabs in that file to 4 spaces, per the
discussion. I also noticed and fixed a
Tom Lane [EMAIL PROTECTED] writes:
This should include some weasel-wording along the lines of At
present, blah blah blah.
Good point, thanks.
It is theoretically legal to reorder outer joins in some cases
Indeed; see Outerjoin Simplification and Reordering for Query
Optimization by
Brian Moore [EMAIL PROTECTED] writes:
please find attached my support for printing/exporting
xml from postgresql.
A few quick comments:
- why is it necessary to include an entire hash table implementation?
Why does this code require a hash table to begin with, considering
the relatively
Brian Moore [EMAIL PROTECTED] writes:
it's not necessary. i ran tests and the hashtable lookup was faster
(though not by too much) than the bsearch for the data with which i
populated the table.
Right -- I'd expect the performance difference between the two to be
pretty negligible for even the
The new C version of initdb presently provokes the following valgrind
warnings:
==15366==
==15366== Conditional jump or move depends on uninitialised value(s)
==15366==at 0x8049713: mkdir_p (initdb.c:556)
==15366==by 0x8049C8E: mkdatadir (initdb.c:812)
==15366==by 0x804C833: main
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, then *This* patch does it the way I think is clearest. Most of
it is just reindenting.
Unless anyone objects, I'll review and apply this patch within 24
hours.
Thanks for the patch, Dennis and Andrew.
-Neil
---(end of
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, then *This* patch does it the way I think is clearest. Most of it
is just reindenting.
Okay, I applied this patch, and made a few additional cleanups along
the way (the whole function and a couple other things don't need to be
declared in hba.h, for
Another error reported by valgrind on the postmaster ( children) is
the following:
==30568== Source and destination overlap in memcpy(0xBFFFEA30, 0xBFFFEA30, 24)
==30568==at 0x40024224: memcpy (mac_replace_strmem.c:93)
==30568==by 0x82081F3: set_var_from_var (numeric.c:2732)
==30568==
Tom Lane [EMAIL PROTECTED] writes:
This isn't a bug
If that's the case I'm content with not changing the code, but I'd
rather not just take it on faith: can you point me to some authority
that says two objects with the same address do not overlap?
(I checked C99 (draft 843) and while it
Tom Lane [EMAIL PROTECTED] writes:
If we want to get rid of the valgrind warning, a simpler patch would
be to substitute memmove for memcpy
I've made this change and committed it to HEAD.
-Neil
---(end of broadcast)---
TIP 6: Have you searched
Magnus Hagander [EMAIL PROTECTED] writes:
Taking into account Claudios comments on the previous patch, as well as
some more fooling around here of my own, here's a fourth (and final?)
one.
I'll apply this tonight barring any objections.
-Neil
---(end of
Magnus Hagander [EMAIL PROTECTED] writes:
Here is an updated version of the win32 readdir patch.
Do we actually need to apply this to the main CVS tree, or can we just
wait for a mingw release that includes the fix?
-Neil
---(end of
Claudio Natoli [EMAIL PROTECTED] writes:
Under Win32, stat() returns an st_ino field, but it has no meaning (on
Win2K, and possibly all Win32 variants, it is always 0).
MSDN says:
Number of the information node (the inode) for the file
(UNIX-specific). On UNIX file systems, the inode
Bruce Momjian [EMAIL PROTECTED] writes:
In reading the patch, it seems he is only doing zero equals
unknown on Win32, so I think we are fine.
That's what I was trying to avoid: where possible, we shouldn't
introduce platform-dependent #ifdefs IMHO.
-Neil
---(end of
Scott Goodwin [EMAIL PROTECTED] writes:
If anyone cares to, I'd still like feedback on anything I could have
done better in this patch
Since, you asked, two minor points: (1) palloc() is for memory
allocation in the backend; use malloc() (or a wrapper like
pg_malloc()) in frontend apps and
Bruce Momjian [EMAIL PROTECTED] writes:
We will document this on the win32 TODO list and remove this patch once
MinGW is fixed.
IIRC, Tom and I both suggested that there is no need to clutter the
source tree with a temporary workaround for a platform that hasn't
even seen a stable release yet.
Bruce Momjian [EMAIL PROTECTED] writes:
Your patch has been added to the PostgreSQL unapplied patches list
at:
In addition to the design problems raised elsewhere, I just wanted to
add that there are as-yet-unaddressed implementation issues with this
patch: I have yet to see a convincing
This patch fixes a minor error message inconsistency. When rejecting
input to the oid type, the following error message is emitted:
nconway=# select 'd'::oid;
ERROR: invalid input syntax for type oid: d
This patch removes the quotes from oid, to make this error message
consistent with the error
Tom Lane [EMAIL PROTECTED] writes:
I'm inclined to apply this but I can see where a person not comfortable
with flex might feel differently. Opinions?
Looks good to me. The psql cleanup is nice, and ISTM that much of the
flex code is comments or flex boilerplate anyway, so the actual LOC
Dennis Bjorklund [EMAIL PROTECTED] writes:
Here is a small doc patch that says that initcap lowercases the rest
of the characters in the string. The current doc suggests that it
only touches the first character in each word, which is not what the
function does.
The improved text is still
Andrew Dunstan wrote:
There appears to be a missing row closing tag in funcs.sgml, which made
make html complain loudly for me. Fix below.
Thanks; patch applied.
(As I noted in the commit message, I didn't notice this mistake
because my version of OpenJade doesn't complain...)
-Neil
Attached is a crude patch to enable some additional jade/openjade
warnings. This should help us catch improper or ill-advised SGML in
the docs.
I disabled the warning for empty tags, as they are used throughout the
SGML docs and there is no point in getting rid of them. I also
disabled the
Peter Eisentraut wrote:
If that doesn't create any new warnings on the current (fixed) code,
then I agree with this.
(Right, it does not.)
However, I'd like to see it factored more to
avoid repeating it for jade and nsgmls. The warning flags are in fact
SP flags, not Jade flags; only Jade is
I've applied the attached patch to HEAD. It does the following:
Add a few more cross-references where appropriate, add more text about
the FROM clause and an example to the UPDATE reference page, and make
a few other SGML tweaks.
Suggestions for further improvement (for example, to the UPDATE
This patch makes the following changes
- emit a warning when an empty string is input to the float4, float8,
and oid types, per earlier discussion on -hackers
- emit a warning when there is trailing whitespace in the input to the
oid type, per suggestion from Tom (BTW, I couldn't see anything
Peter Eisentraut wrote:
ISTM that the linking changes you propose are stretching the semantics
of DocBook. If you want to link, why not just use link. By using
xref plus endterm you're doing the same thing indirectly and you rely
on the remote endterm having a sensible grammatical structure
1 - 100 of 833 matches
Mail list logo
