On Thu, 2005-13-10 at 00:39 -0600, Michael Fuhr wrote:
> *** doc/src/sgml/cvs.sgml 11 Aug 2005 13:52:33 - 1.34
> --- doc/src/sgml/cvs.sgml 13 Oct 2005 06:15:38 -
> ***
> *** 849,855
> to you the malloc code and an additional installation e-mail from
> Joh
Michael Fuhr wrote:
I took the liberty of making the following spelling changes for
consistency with the rest of the documentation, even though the
originals are the preferred spellings in some parts of the English-
speaking world. I found only one or two instances of each; the
latter forms w
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Andrew Dunstan
> Sent: 13 October 2005 14:56
> To: Michael Fuhr
> Cc: pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] Documentation typos
>
>
> You seem to have lots of time on your hands
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Is there an official spelling standard for PostgreSQL?
There is not. Given that a substantial fraction of our community is
accustomed to British spellings, I've never felt that it was appropriate
to try to standardize either way. I just leave it the w
On Thu, Oct 13, 2005 at 09:55:55AM -0400, Andrew Dunstan wrote:
> You seem to have lots of time on your hands if you can worry about this.
> How you spend it is your business, of course, but playing spelling cop
> doesn't seem worth it to me.
Whether you agree or not, some people judge a product
On Thu, 2005-13-10 at 09:55 -0400, Andrew Dunstan wrote:
> You seem to have lots of time on your hands if you can worry about this.
> How you spend it is your business, of course, but playing spelling cop
> doesn't seem worth it to me.
I think it's a perfectly valid thing to fix. Part of quality
On Thu, 2005-13-10 at 10:16 -0400, Tom Lane wrote:
> Given that a substantial fraction of our community is accustomed to
> British spellings, I've never felt that it was appropriate to try to
> standardize either way.
The same reasoning applies to the audience of (and contributors to) most
publica
Michael Fuhr wrote:
On Thu, Oct 13, 2005 at 09:55:55AM -0400, Andrew Dunstan wrote:
You seem to have lots of time on your hands if you can worry about this.
How you spend it is your business, of course, but playing spelling cop
doesn't seem worth it to me.
Whether you agree or not,
I need a comment on this.
---
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > Here's a patch that fixes the big problem and reverts the behaviour of
> > appl_version to be compatible with 8.0.
>
> Applie
I need a comment on this.
---
Tom Lane wrote:
> BTW, it appears to me that this patch has also broken the claim in the
> manual that
>
> If [krb_server_hostname is] not set, the default is to allow any
> service
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Sokolov Yura wrote:
> Excuse my English.
> Patch allows to get triggers table name in the trigger TD['relname'].
> Us
Patch applied. Thanks. Your documentation changes can be viewed in
five minutes using links on the developer's page,
http://www.postgresql.org/developer/testing.
---
Simon Riggs wrote:
>
> Some additional doc changes ba
Thomas Hallgren wrote:
> Tom Lane wrote:
>
> >Thomas Hallgren <[EMAIL PROTECTED]> writes:
> >
> >
> >>Here is a patch that will enable a module to change the stack_base_ptr
> >>temporarilly during a call.
> >>
> >>
> >
> >I'm not really in favor of this ... I think you are trying to make th
Bruce Momjian writes:
>> Tom Lane wrote:
>>> I'm not really in favor of this ... I think you are trying to make the
>>> backend do something that will never work reliably.
> Do we want to make this change for 8.1?
I don't want to do it at all. The justification given is to allow the
backend to
On Thu, 2005-13-10 at 12:17 -0400, Andrew Dunstan wrote:
> I don't agree that we need to force one spelling of common words when
> many dictionaries recognise the validity of variant spellings.
There is obviously no "need" to force the use of one spelling variant or
another. However, I think it is
Tom Lane wrote:
> Bruce Momjian writes:
> >> Tom Lane wrote:
> >>> I'm not really in favor of this ... I think you are trying to make the
> >>> backend do something that will never work reliably.
>
> > Do we want to make this change for 8.1?
>
> I don't want to do it at all. The justification g
Tom has already applied a fix for this:
http://archives.postgresql.org/pgsql-committers/2005-10/msg00114.php
//Magnus
>
> I need a comment on this.
>
> --
> -
>
> Tom Lane wrote:
> > "Magnus Hagander" <[EMAIL PROTECTED]>
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Tom has already applied a fix for this:
> http://archives.postgresql.org/pgsql-committers/2005-10/msg00114.php
I requested more docs changes from you, though.
regards, tom lane
---(end of broadcast)--
(Tom, this is the other one you were referring to, I hope.)
I'm still planning to do this, but I'm very pressed for time right now.
I'll try to get it done as soon as possible, but worst case it may be
around two weeks before I can do it. Sorry. If someone else wants to
beat me to it go right ahea
We don't have two weeks, I think. If I can catch you on IM I can make
the modifications, with a little hand-holding.
---
Magnus Hagander wrote:
> (Tom, this is the other one you were referring to, I hope.)
>
> I'm still pl
Steve Woodcock wrote:
> Hi,
>
> This makes the error messages for PREPARE TRANSACTION, COMMIT PREPARED
> etc. match the docs, which talk about "transaction identifier" not
> "gid" or "global transaction identifier".
Agreed. However, haven't we frozen the error strings? This arrived
October 2 wh
Bruce Momjian writes:
> We don't have two weeks, I think. If I can catch you on IM I can make
> the modifications, with a little hand-holding.
For docs changes I think we do. I'm a bit worried however about whether
the loss of wildcard functionality is a problem requiring code changes.
Bruce Momjian writes:
> Steve Woodcock wrote:
>> This makes the error messages for PREPARE TRANSACTION, COMMIT PREPARED
>> etc. match the docs, which talk about "transaction identifier" not
>> "gid" or "global transaction identifier".
> Agreed. However, haven't we frozen the error strings? This
Tom Lane wrote:
Bruce Momjian writes:
Tom Lane wrote:
I'm not really in favor of this ... I think you are trying to make the
backend do something that will never work reliably.
Do we want to make this change for 8.1?
I don't want to do it at all. The justificat
On Thu, Oct 13, 2005 at 01:48:11PM -0400, Neil Conway wrote:
> On Thu, 2005-13-10 at 12:17 -0400, Andrew Dunstan wrote:
> > I don't agree that we need to force one spelling of common words when
> > many dictionaries recognise the validity of variant spellings.
>
> There is obviously no "need" to f
Michael Fuhr wrote:
That's 5 changes out of 245 total occurrences.
So what? I just don't see consistency as being a value in itself, but
only when it has some other merit. Clearly you don't agree, but I am
with Emerson on the subject of consistency.
cheers
andrew
--
Andrew Dunstan wrote:
> Is there an official spelling standard for PostgreSQL?
While nothing is ever really official around here, the documentation is
susceptible to being hit by my spell-checking tool, which has
historically tended to use whatever "american" aspell dictionary I had
installed a
> > We don't have two weeks, I think. If I can catch you on IM
> I can make
> > the modifications, with a little hand-holding.
>
> For docs changes I think we do. I'm a bit worried however
> about whether the loss of wildcard functionality is a problem
> requiring code changes.
Well, we did
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> For docs changes I think we do. I'm a bit worried however
>> about whether the loss of wildcard functionality is a problem
>> requiring code changes.
> Well, we didn't have it in 8.0.
Oh, OK. I had been thinking it was pre-existing behavior, bu
Neil Conway wrote:
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/writing-s
>tyle.html
I can heartily recommend this, and I have deferred to this many times
over the years.
I disagree with the point on "Avoid redundant phrases", though, and in
fact it contradicts error message st
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Karel Zak wrote:
>
> Hi,
>
> attached is a patch that implements "COPY view TO" feature.
>
> Karel
>
> Exa
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
David Fetter wrote:
> On Wed, Sep 28, 2005 at 04:30:54PM +0200, Pavel Stehule wrote:
> > Hello
> >
> > base type cha
Patch applied. Thanks.
---
Kris Jurka wrote:
>
> The patch updates the documentation to reflect the fact that higher values
> of client_min_messages (fatal + panic) are valid and also fixes a slight
> issue with how psq
This has been fixed in current CVS:
krb_srvname/krb_server_hostname@REALM.
---
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > Here's a patch that fixes the big problem and reverts the behaviour of
>
Magnus Hagander wrote:
>
> Tom has already applied a fix for this:
> http://archives.postgresql.org/pgsql-committers/2005-10/msg00114.php
Ah, I see now. Sorry I missed it.
---
>
> //Magnus
>
> >
> > I need a comment on
Tom Lane wrote:
> BTW, it appears to me that this patch has also broken the claim in the
> manual that
>
> If [krb_server_hostname is] not set, the default is to allow any
> service principal matching an entry in the keytab.
>
> The reason that was true was that we passed a NULL "server" value to
Patch applied. Thanks.
---
Steve Woodcock wrote:
> Hi,
>
> This makes the error messages for PREPARE TRANSACTION, COMMIT PREPARED
> etc. match the docs, which talk about "transaction identifier" not
> "gid" or "global tra
So what? I just don't see consistency as being a value in itself, but
only when it has some other merit. Clearly you don't agree, but I am
with Emerson on the subject of consistency.
So you're saying you're consistent in your objections to consistency? :)
---(end of br
Michael Fuhr wrote:
> On Thu, Oct 13, 2005 at 09:49:20AM -0600, Michael Fuhr wrote:
> > ecpg in 8.0.4 seems not to like the macros. I get the same error,
> > but not if I do this:
> >
> > VARCHAR t[256];
> > VARCHAR o[256];
> >
> > ecpg in 8.1beta3 works either way.
>
> This appears t
I have written the attached patch which I think does what you suggested.
I found all the places where we disallowed 24:00:00, and make it valid,
including nabstime.c.
test=> select '24:00:00'::time(0);
time
--
24:00:00
(1 row)
Bruce Momjian writes:
> I have written the attached patch which I think does what you suggested.
> I found all the places where we disallowed 24:00:00, and make it valid,
> including nabstime.c.
Looks reasonable right offhand ... don't forget to update the docs too.
regar
41 matches
Mail list logo
