Re: [PATCHES] Documentation typos
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 > John. > > The Modula-3 installation takes a good bit of room (~50MB?) and the > ! build environment is unique to Modula-3, but suprisingly enough it > pretty much works. > > The cvsup Makefiles do not work on my machine (they are not portable > --- 849,855 > to you the malloc code and an additional installation e-mail from > John. > > The Modula-3 installation takes a good bit of room (~50MB?) and the > ! build environment is unique to Modula-3, but surprisingly enough it > pretty much works. > > The cvsup Makefiles do not work on my machine (they are not > portable This change modifies an SGML comment that contains the text of an email thread, so it is debatable whether we should be modifying it. However, is there a good reason for this comment to be in cvs.sgml to begin with? I agree we should pick American or British spelling and use one consistently. Barring any objections, I'll apply the rest of the patch within a day or two. -Neil ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Documentation typos
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 were far more common. behaviour=> behavior organisation => organization recognised => recognized recognises => recognizes 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. Is there an official spelling standard for PostgreSQL? If so, where is it stated? If we are going to adopt one I'd vote for the OED :-) I am so unconscious of it that it will be impossible for me to undo the habits of a lifetime, and I suspect I am not alone, so this would be a never ending battle. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Documentation typos
> -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 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. > > Is there an official spelling standard for PostgreSQL? If so, > where is > it stated? If we are going to adopt one I'd vote for the OED > :-) I am so > unconscious of it that it will be impossible for me to undo > the habits > of a lifetime, and I suspect I am not alone, so this would be a never > ending battle. I'm inclined to agree, but then maybe that's because I'm about 8 miles from Oxford right now, and spent years at school being told off for spelling things in American. Regards, Dave. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Documentation typos
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 way the author of that particular bit of documentation wrote it. regards, tom lane ---(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: [PATCHES] Documentation typos
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 in part by the quality of its documentation. Spelling mistakes detract from that quality, and since it takes only a few minutes with a spellchecker to find and fix them, the effort does seem worth it to me. You might consider that statements such as the above only discourage people from taking such efforts. Regarding American vs. British spelling, my spellchecker flagged the latter, so I did a quick grep to see which was the more prevalent in the rest of the documentation and made them all the same for consistency. It doesn't matter to me which we use, but my vote would be that we use one form consistently rather than mix them. -- Michael Fuhr ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Documentation typos
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 is getting the details right, and following consistent conventions for spelling and grammar in the documentation is part of that. > Is there an official spelling standard for PostgreSQL? No, although I think there ought to be one. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Documentation typos
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 publications. AFAIK it is not considered good style to mix spelling variants freely -- we should pick one variant and use it consistently. (If we're going to be really precise, we could also decide to follow a set of conventions on punctuation, capitalization, and other minor style issues, but I can't get too excited about it.) -Neil ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Documentation typos
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, some people judge a product in part by the quality of its documentation. Spelling mistakes detract from that quality, and since it takes only a few minutes with a spellchecker to find and fix them, the effort does seem worth it to me. You might consider that statements such as the above only discourage people from taking such efforts. Regarding American vs. British spelling, my spellchecker flagged the latter, so I did a quick grep to see which was the more prevalent in the rest of the documentation and made them all the same for consistency. It doesn't matter to me which we use, but my vote would be that we use one form consistently rather than mix them. I was (perhaps badly) attempting to be mildly humorous. I agree that typos should be fixed. I don't agree that we need to force one spelling of common words when many dictionaries recognise the validity of variant spellings. English is not a precisely defined language - that's part of its beauty. I live in a part of the world where pronunciation can be truly mystifying, and spelling can often be also. You learn to live with it. cheers andrew (who refuses to spell aluminium with only one i) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
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. > > Applied with trivial stylistic cleanups. > > BTW, the documentation seems a bit broken: > > krb_server_hostname (string) > > Sets the hostname part of the service principal. This, combined > with krb_srvname, is used to generate the complete service > principal, i.e. krb_server_hostname/[EMAIL PROTECTED] > > I suppose one of those last two should be "krb_srvname", but which? > > regards, tom lane > > ---(end of broadcast)--- > TIP 1: 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 > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
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 principal matching an entry in the keytab. > > The reason that was true was that we passed a NULL "server" value to > krb5_recvauth(), which with this patch we never do anymore. > > I'm not sure if this represents a serious loss of flexibility or not, > but in any case the documentation needs an update. > > regards, tom lane > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Patch for PLPYTHONU - adding TD["relname"]
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'].
> Usefull when same trigger function applied to different tables.
> patch for plpython.c in Postgres 8.1 beta (diff was applied to)
> works also in Postgres 8.0.3 when placed in the same function (may be
> different line numbers)
>
> --- plpython-old.c2005-07-10 08:56:55.0 +0400
> +++ plpython.c2005-10-04 12:03:36.0 +0400
> @@ -582,7 +582,8 @@ PLy_trigger_build_args(FunctionCallInfo
> *pltevent,
> *pltwhen,
> *pltlevel,
> - *pltrelid;
> + *pltrelid,
> + *pltrelname;
> PyObject *pltargs,
> *pytnew,
> *pytold;
> @@ -606,6 +607,12 @@ PLy_trigger_build_args(FunctionCallInfo
> Py_DECREF(pltrelid);
> pfree(stroid);
>
> +stroid = SPI_getrelname(tdata->tg_relation);
> +pltrelname = PyString_FromString(stroid);
> +PyDict_SetItemString(pltdata, "relname", pltrelname);
> +Py_DECREF(pltrelname);
> +pfree(stroid);
> +
> if (TRIGGER_FIRED_BEFORE(tdata->tg_event))
> pltwhen = PyString_FromString("BEFORE");
> else if (TRIGGER_FIRED_AFTER(tdata->tg_event))
>
>
>
> ---(end of broadcast)---
> TIP 2: Don't 'kill -9' the postmaster
>
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Docs for PITR and full_page_writes interaction
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 based around compression of page images in > WAL and the interaction of the new full_page_writes parameter with PITR. > > The too-small WAL first sect1 has been merged with the one following > sect1 for clarity. > > Some minor comments have been made in the WAL config section also. > > Passes SGML make and proofread for typos. > Files changed: > patching file doc/src/sgml/backup.sgml > patching file doc/src/sgml/config.sgml > patching file doc/src/sgml/wal.sgml > > Best Regards, Simon Riggs [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Path to enable a module to change the stack_base_ptr
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 the > >backend do something that will never work reliably. > > > >If we were to try to support this, I'd prefer to just make > >stack_base_ptr non static, rather than add overhead code. > > > > regards, tom lane > > > > > Sure, that works for me. Do we want to make this change for 8.1? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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: [PATCHES] Path to enable a module to change the stack_base_ptr
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 support multithreading introduced by an add-on library, which is a hopeless cause. Removing "static" from that variable declaration is surely a cheap enough change, but what about the next request, and the one after that? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Documentation typos
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 good style to consistently use either American or British English. To pick the first example from Google, the FreeBSD documentation group do this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/writing-style.html And they face many of the same challenges we do as far as contributors from different regions of the world. -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Path to enable a module to change the stack_base_ptr
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 given is to allow the > backend to support multithreading introduced by an add-on library, which > is a hopeless cause. Removing "static" from that variable declaration > is surely a cheap enough change, but what about the next request, and > the one after that? Well, I have not seen the next request yet, but it seems harmless for a useful extension to the database, namely PL/Java. I do believe this is one of the reasons PL/J took a different approach, though. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
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]> writes: > > > Here's a patch that fixes the big problem and reverts the > behaviour > > > of appl_version to be compatible with 8.0. > > > > Applied with trivial stylistic cleanups. > > > > BTW, the documentation seems a bit broken: > > > > krb_server_hostname (string) > > > > Sets the hostname part of the service principal. This, combined > > with krb_srvname, is used to generate the complete service > > principal, i.e. krb_server_hostname/[EMAIL PROTECTED] > > > > I suppose one of those last two should be "krb_srvname", but which? > > > > regards, tom lane > > > > ---(end of > > broadcast)--- > > TIP 1: 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 > > > > -- > Bruce Momjian| http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, > Pennsylvania 19073 > ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
"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)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
(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 ahead, otherwise - it's on it's way eventually. I think a general overview to make sure the different parts (config section vs kerberos auth section) are actually in sync is required. //Magnus > > 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 principal matching an entry in the keytab. > > > > The reason that was true was that we passed a NULL "server" > value to > > krb5_recvauth(), which with this patch we never do anymore. > > > > I'm not sure if this represents a serious loss of > flexibility or not, > > but in any case the documentation needs an update. > > > > regards, tom lane > > > > ---(end of > > broadcast)--- > > TIP 5: don't forget to increase your free space map settings > > > > -- > Bruce Momjian| http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, > Pennsylvania 19073 > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
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 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 ahead, otherwise - it's on it's way eventually. > I think a general overview to make sure the different parts (config > section vs kerberos auth section) are actually in sync is required. > > //Magnus > > > > > 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 principal matching an entry in the keytab. > > > > > > The reason that was true was that we passed a NULL "server" > > value to > > > krb5_recvauth(), which with this patch we never do anymore. > > > > > > I'm not sure if this represents a serious loss of > > flexibility or not, > > > but in any case the documentation needs an update. > > > > > > regards, tom lane > > > > > > ---(end of > > > broadcast)--- > > > TIP 5: don't forget to increase your free space map settings > > > > > > > -- > > Bruce Momjian| http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 359-1001 > > + If your life is a hard drive, | 13 Roberts Road > > + Christ can be your backup.| Newtown Square, > > Pennsylvania 19073 > > > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Make 2PC error messages match docs
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 when I think the change could have been made, but now, can we? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
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. regards, tom lane ---(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: [PATCHES] Make 2PC error messages match docs
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 arrived > October 2 when I think the change could have been made, but now, can we? Peter has been editorializing on the messages over the past week or two (I assume when he comes across something he doesn't like while translating), so the freeze doesn't seem that hard to me. I'm fine with that patch. Peter, what's your opinion? regards, tom lane ---(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: [PATCHES] Path to enable a module to change the stack_base_ptr
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 given is to allow the backend to support multithreading introduced by an add-on library, which is a hopeless cause. Removing "static" from that variable declaration is surely a cheap enough change, but what about the next request, and the one after that? Tom, I don't request that the backend should support multiple threads simultaneously. It's one thread at a time. I can't think of a "next request" in this direction. I'm very aware that the backend is single-threaded and that you have no intention to change that. Neither do I. Having the stack_base public is actually useful for another purpose also. It can allow you to make assertions that check if an abitrary pointer is 'on stack' or not. The MemoryContextContains() could be made safer too by just returning false when the given pointer is between the stack_base and the current stack_pointer. Perhaps that could be added to the patch? Regards, Thomas Hallgren ---(end of broadcast)--- TIP 1: 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: [PATCHES] Documentation typos
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 force the use of one spelling variant or > another. However, I think it is good style to consistently use either > American or British English. To give an idea of the scope of the changes I submitted, here are counts for the words I changed and their variants: 2 behaviour 195 behavior 1 organisation6 organization 1 recognised 35 recognized 1 recognises 4 recognizes That's 5 changes out of 245 total occurrences. -- Michael Fuhr ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Documentation typos
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Documentation typos
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 at the time. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
> > 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 didn't have it in 8.0. And I'm not even sure it ever worked in 8.1dev - it certainly didn't work in my case. So. *I* think we're fine with removing it, as long as we update the docs to be in sync. But perhaps someone who actually used it can confirm if it's worthwhile? //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
"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, but if it's not then there's no issue. I'm fine with pulling out a feature that wasn't there in 8.0 --- if someone wants it, they can figure out how to make it work properly and submit for 8.2 or later. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Documentation typos
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 style guideline 43.3.9., so it's explicit. :) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] COPY view
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 > > Example: > > test=# CREATE VIEW vvv AS SELECT a.id, a.data AS d1, b.data AS d2 FROM > tab a, tab2 b WHERE a.id=b.fk; > CREATE VIEW > test=# COPY vvv TO '/tmp/test'; > COPY > test=# \! cat /tmp/test > 1 aaa AAA > 2 bbb BBB > 3 ccc CCC > 4 ddd DDD > > > -- > Karel Zak <[EMAIL PROTECTED]> [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] SQL/XML publishing function experimental patch II
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 changed to text, better registration xmlagg function > > > > Regards Pavel Stehule > > Now with some slightly improved documentation, works vs. CVS tip as of > this writing. > > Cheers, > D > -- > David Fetter [EMAIL PROTECTED] http://fetter.org/ > phone: +1 510 893 6100 mobile: +1 415 235 3778 > > Remember to vote! [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] high values for client_min_messages
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 psql tried to display error messages that aren't sent to > the client. > > We often tell people to ignore errors in response to requests for things > like "drop if exists", but there's no good way to completely hide this > without upping client_min_messages past ERROR. When running a file like > > SET client_min_messages TO 'FATAL'; > > DROP TABLE doesntexist; > > with "psql -f filename" you get an error prefix of > "psql:/home/username/filename:3" even though there is no error message to > prefix because it isn't sent to the client. > > Kris Jurka Content-Description: [ Attachment, skipping... ] > > ---(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 -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
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 > > appl_version to be compatible with 8.0. > > Applied with trivial stylistic cleanups. > > BTW, the documentation seems a bit broken: > > krb_server_hostname (string) > > Sets the hostname part of the service principal. This, combined > with krb_srvname, is used to generate the complete service > principal, i.e. krb_server_hostname/[EMAIL PROTECTED] > > I suppose one of those last two should be "krb_srvname", but which? > > regards, tom lane > > ---(end of broadcast)--- > TIP 1: 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 > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
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 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. > > > > > > Applied with trivial stylistic cleanups. > > > > > > BTW, the documentation seems a bit broken: > > > > > > krb_server_hostname (string) > > > > > > Sets the hostname part of the service principal. This, combined > > > with krb_srvname, is used to generate the complete service > > > principal, i.e. krb_server_hostname/[EMAIL PROTECTED] > > > > > > I suppose one of those last two should be "krb_srvname", but which? > > > > > > regards, tom lane > > > > > > ---(end of > > > broadcast)--- > > > TIP 1: 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 > > > > > > > -- > > Bruce Momjian| http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 359-1001 > > + If your life is a hard drive, | 13 Roberts Road > > + Christ can be your backup.| Newtown Square, > > Pennsylvania 19073 > > > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: 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: [PATCHES] [HACKERS] Kerberos brokenness and oops question in 8.1beta2
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
> krb5_recvauth(), which with this patch we never do anymore.
>
> I'm not sure if this represents a serious loss of flexibility or not,
> but in any case the documentation needs an update.
I did some research on this and I think I have the answer. The original
patch came from here (I have CC'ed the author):
http://archives.postgresql.org/pgsql-patches/2005-06/msg00293.php
I applied his second patch. As part of that patch he states:
> The second patch (kovert-krb5-patch-newbehavior.txt) makes the default
> behavior to accept any principal in the keytab. This means that people
> using kerberos will continue to work, but they'll be slightly more
> broad in what they accept as a valid service principal (I suspect
> there's very few people in the world who care about this since it still
> needs to be something in the keytab).
Now, our code has been modified since his patch was applied, but we now
have:
/*
* If no hostname was specified, pg_krb_server_hostname is already
* NULL. If it's set to blank, force it to NULL.
*/
khostname = pg_krb_server_hostname;
if (khostname && khostname[0] == '\0')
khostname = NULL;
retval = krb5_sname_to_principal(pg_krb5_context,
khostname,
pg_krb_srvnam,
KRB5_NT_SRV_HST,
&pg_krb5_server);
The basic affect is if the GUC krb_server_hostname is empty/NULL,
krb5_sname_to_principal() gets called with a 2nd argument (hostname) of
NULL. The documentation for this function says for this argument:
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/index.htm?info/apis/krb5list.htm
hostname (Input)
The host containing the desired service instance. The local host is used
if NULL is specified for this parameter.
Which says it doesn't accept any service entry in keytab, but rather
binds the server hostname to 'localhost'. I think this is why it wasn't
working for Magnus.
I have applied the following patch which updates the documentation to
reflect 'localhost', and improves the error message to always print the
server name as well as the service name. (We have had complaints about
poor Kerberos error messages before.)
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/config.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v
retrieving revision 1.27
diff -c -c -r1.27 config.sgml
*** doc/src/sgml/config.sgml13 Oct 2005 20:58:42 - 1.27
--- doc/src/sgml/config.sgml13 Oct 2005 22:43:43 -
***
*** 596,604
krb_srvname/krb_server_hostname@REALM.
! If not set, the default is to allow any service principal matching an
entry
! in the keytab. See for details.
! This parameter can only be set at server start.
--- 596,603
krb_srvname/krb_server_hostname@REALM.
! If not set, the default is localhost. See
! for details. This parameter can only be set at server start.
Index: src/backend/libpq/auth.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/auth.c,v
retrieving revision 1.128
diff -c -c -r1.128 auth.c
*** src/backend/libpq/auth.c8 Oct 2005 19:32:57 - 1.128
--- src/backend/libpq/auth.c13 Oct 2005 22:43:44 -
***
*** 162,172
if (retval)
{
ereport(LOG,
! (errmsg("Kerberos sname_to_principal(\"%s\")
returned error %d",
! pg_krb_srvnam, retval)));
com_err("postgres", retval,
! "while getting server principal for service
\"%s\"",
! pg_krb_srvnam);
krb5_kt_close(pg_krb5_context, pg_krb5_keytab);
krb5_free_context(pg_krb5_context);
return STATUS_ERROR;
--- 162,172
if (retval)
{
ereport(LOG,
! (errmsg("Kerberos sname_to_principal(\"%s\",
\"%s\") returned error %d",
! khostname ? khostname :
"localhost", pg_krb_srvnam, re
Re: [PATCHES] Make 2PC error messages match docs
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 transaction identifier". > > Regards, Steve Woodcock [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Documentation typos
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 broadcast)--- TIP 1: 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: [PATCHES] [BUGS] BUG #1962: ECPG and VARCHAR
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 to be the guilty commit, which was made to 7.4, 8.0, > and HEAD (8.1): > > http://archives.postgresql.org/pgsql-committers/2005-08/msg00266.php > > It was recently fixed in HEAD only: > > http://archives.postgresql.org/pgsql-committers/2005-10/msg00043.php Good catch! I have backpatched these fixes to the 8.0 and 7.4 branches as you suggested, (identical) patches attached. The big problem is that we might not make releases on these branches for months, so anyone needing the fix should download CVS for those branches. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/interfaces/ecpg/preproc/preproc.y === RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/preproc.y,v retrieving revision 1.303.4.4 diff -c -c -r1.303.4.4 preproc.y *** src/interfaces/ecpg/preproc/preproc.y 24 Aug 2005 10:35:12 - 1.303.4.4 --- src/interfaces/ecpg/preproc/preproc.y 14 Oct 2005 01:47:05 - *** *** 5142,5149 *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* if (strcmp(length, "0") == 0)*/ ! if (atoi(length) <= 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0) --- 5142,5149 *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* cannot check for atoi <= 0 because a defined constant will yield 0 here as well */ ! if (atoi(length) < 0 || strcmp(length, "0") == 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0) Index: src/interfaces/ecpg/preproc/preproc.y === RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/preproc.y,v retrieving revision 1.263.2.20 diff -c -c -r1.263.2.20 preproc.y *** src/interfaces/ecpg/preproc/preproc.y 24 Aug 2005 10:35:54 - 1.263.2.20 --- src/interfaces/ecpg/preproc/preproc.y 14 Oct 2005 01:47:43 - *** *** 5121,5128 *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* if (strcmp(length, "0") == 0)*/ ! if (atoi(length) <= 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0) --- 5121,5128 *dim = '\0'; else sprintf(dim, "[%s]", dimension); ! /* cannot check for atoi <= 0 because a defined constant will yield 0 here as well */ ! if (atoi(length) < 0 || strcmp(length, "0") == 0) mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented"); if (strcmp(dimension, "0") == 0) ---(end of broadcast)--- TIP 1: 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: [PATCHES] [HACKERS] roundoff problem in time datatype
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) test=> select '24:00:01'::time(0); ERROR: date/time field value out of range: "24:00:01" --- Tom Lane wrote: > Inserting into a time field with limited precision rounds off, which > is good except for this case: > > regression=# select '23:59:59.9'::time(0); >time > -- > 24:00:00 > (1 row) > > This is bad because: > > regression=# select '24:00:00'::time(0); > ERROR: date/time field value out of range: "24:00:00" > > which means that data originally accepted will fail to dump and reload. > > I see this behavior in all versions back to 7.3. 7.2 was even more > broken: > > regression=# select '23:59:59.9'::time(0); >time > -- > 00:00:00 > (1 row) > > I think the correct behavior has to be to check for overflow again > after rounding off. Alternatively: why are we forbidding the value > 24:00:00 anyway? Is there a reason not to allow the hours field > to exceed 23? > > regards, tom lane > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: src/backend/utils/adt/datetime.c === RCS file: /cvsroot/pgsql/src/backend/utils/adt/datetime.c,v retrieving revision 1.158 diff -c -c -r1.158 datetime.c *** src/backend/utils/adt/datetime.c9 Oct 2005 17:21:46 - 1.158 --- src/backend/utils/adt/datetime.c14 Oct 2005 02:52:39 - *** *** 1114,1120 * Check upper limit on hours; other limits checked in * DecodeTime() */ ! if (tm->tm_hour > 23) return DTERR_FIELD_OVERFLOW; break; --- 1114,1122 * Check upper limit on hours; other limits checked in * DecodeTime() */ ! /* test for > 24:00:00 */ ! if (tm->tm_hour > 24 || !(tm->tm_hour == 24 && (tm->tm_min > 0 || tm->tm_sec > 0))) return DTERR_FIELD_OVERFLOW; break; *** *** 2243,2256 else if (mer == PM && tm->tm_hour != 12) tm->tm_hour += 12; #ifdef HAVE_INT64_TIMESTAMP ! if (tm->tm_hour < 0 || tm->tm_hour > 23 || tm->tm_min < 0 || ! tm->tm_min > 59 || tm->tm_sec < 0 || tm->tm_sec > 60 || *fsec < INT64CONST(0) || *fsec >= USECS_PER_SEC) return DTERR_FIELD_OVERFLOW; #else ! if (tm->tm_hour < 0 || tm->tm_hour > 23 || tm->tm_min < 0 || ! tm->tm_min > 59 || tm->tm_sec < 0 || tm->tm_sec > 60 || *fsec < 0 || *fsec >= 1) return DTERR_FIELD_OVERFLOW; #endif --- 2245,2260 else if (mer == PM && tm->tm_hour != 12) tm->tm_hour += 12; + if (tm->tm_hour < 0 || tm->tm_min < 0 || tm->tm_min > 59 || + tm->tm_sec < 0 || tm->tm_sec > 60 || tm->tm_hour > 24 || + /* Allow 24:00:00 */ + (tm->tm_hour == 24 && (tm->tm_min > 0 || tm->tm_sec > 0 || #ifdef HAVE_INT64_TIMESTAMP ! *fsec > INT64CONST(0))) || *fsec < INT64CONST(0) || *fsec >= USECS_PER_SEC) return DTERR_FIELD_OVERFLOW; #else ! *fsec > 0)) || *fsec < 0 || *fsec >= 1) return DTERR_FIELD_OVERFLOW; #endif Index: src/backend/utils/adt/nabstime.c === RCS file: /cvsroot/pgsql/src/backend/utils/adt/nabstime.c,v retrieving revision 1.143 diff -c -c -r1.143 nabstime.c *** src/backend/utils/adt/nabstime.c24 Sep 2005 22:54:38 - 1.143 --- src/backend/utils/adt/nabstime.c14 Oct 2005 02:52:40 - *** *** 187,193 if (tm->tm_year < 1901 || tm->tm_year > 2038 || tm->tm_mon < 1 || tm->tm_mon > 12 || tm->tm_mday < 1 || tm->tm_mday > 31 ! || tm->tm_hour < 0 || tm->tm_hour > 23 || tm->tm_min < 0 || tm->tm_min > 59
Re: [PATCHES] [HACKERS] roundoff problem in time datatype
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. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
