Re: [HACKERS] Open 8.3 issues
On Sat, 2007-11-24 at 17:06 -0500, Greg Smith wrote: On Sat, 24 Nov 2007, Tom Lane wrote: [PATCHES] [Fwd: Re: [HACKERS] Postgres 8.3 archive_command], Simon Riggs Applied. Getting positive feedback that your archive command has triggered is helpful for new users of this feature, and making it so that doesn't happen anymore is a step backwards for them as far as I'm concerned. Simon suggested he had a documentation update that was going to cover this. I'd like to see that and a mention of this change in the release notes before this is closed. OK, I'll patch the docs, you patch the release notes, how's that? My notes say I have these doc changes to submit for 8.3 - SQL Standard changes - array references clean-up - locking clarification - PITR clarifications I already thought that the way the archive_command examples do everything as a command line instead of calling a script sets a bad example practice, and unless you call something you don't have options like tweak your archive_command script to do some logging of its own. This change makes a much stronger case for saying outright the archive_command should call a separate script, so you can adjust things including logging there. That concept isn't even introduced by the current documentation. I know I was surprised the first time I echo'd something from the script and discovered it showed up in the server logs. Being able to see what the command is seems like good practice to me, so I don't agree that we should encourage people to use scripts in all cases. But if you say that it isn't clear you can use scripts then that should change, especially the additional messages aspect. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Open 8.3 issues
I have updated the patches queue with open 8.3 items: http://momjian.postgresql.org/cgi-bin/pgpatches FYI, I worked with a Borland CC user offlist and 8.3 CVS now compiles cleanly for him. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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: [HACKERS] Open 8.3 issues
On 11/24/07, Bruce Momjian [EMAIL PROTECTED] wrote: I have updated the patches queue with open 8.3 items: http://momjian.postgresql.org/cgi-bin/pgpatches The Cleaner API for appendStringInfoVA belongs to 8.4, if accepted. It is not serious enough for 8.3. -- marko ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Open 8.3 issues
Marko Kreen wrote: On 11/24/07, Bruce Momjian [EMAIL PROTECTED] wrote: I have updated the patches queue with open 8.3 items: http://momjian.postgresql.org/cgi-bin/pgpatches The Cleaner API for appendStringInfoVA belongs to 8.4, if accepted. It is not serious enough for 8.3. Thanks, updated. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 8.3 issues
Bruce Momjian [EMAIL PROTECTED] writes: I have updated the patches queue with open 8.3 items: http://momjian.postgresql.org/cgi-bin/pgpatches Re: [DOCS] Normalized Ranking example incorrect in text search, Tom Lane This is done already. Re: [HACKERS] Heads up: 8.3beta3 to be wrapped this evening, andrew This too. [PATCHES] Proposed patch for ANALYZE overcounting dead rows, Tom Lane I think the consensus was to push this issue to 8.4. [PATCHES] [Fwd: Re: [HACKERS] Postgres 8.3 archive_command], Simon Riggs Applied. Re: [HACKERS] [PATCHES] Fixes for MONEY type using locale, Bruce Momjian Any feature additions to MONEY will be for 8.4. What is this doing in the 8.3 list? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open 8.3 issues
On Sat, 24 Nov 2007, Tom Lane wrote: [PATCHES] [Fwd: Re: [HACKERS] Postgres 8.3 archive_command], Simon Riggs Applied. Getting positive feedback that your archive command has triggered is helpful for new users of this feature, and making it so that doesn't happen anymore is a step backwards for them as far as I'm concerned. Simon suggested he had a documentation update that was going to cover this. I'd like to see that and a mention of this change in the release notes before this is closed. I already thought that the way the archive_command examples do everything as a command line instead of calling a script sets a bad example practice, and unless you call something you don't have options like tweak your archive_command script to do some logging of its own. This change makes a much stronger case for saying outright the archive_command should call a separate script, so you can adjust things including logging there. That concept isn't even introduced by the current documentation. I know I was surprised the first time I echo'd something from the script and discovered it showed up in the server logs. Sorry I didn't speak up before, I didn't think this was even a serious candidate for applying to 8.3. Seemed like too much of a functional change for slipping in this late and I presumed it was just going into the 8.4 queue. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Open 8.3 issues
I wrote:
Re: [HACKERS] Heads up: 8.3beta3 to be wrapped this evening, andrew
This too.
Uh, no, actually it isn't. I thought we were going to make cases
like h1 be treated as XML tags, but CVS HEAD fails to do that:
regression=# select * from ts_debug('h1foo/h1');
alias | description| token | dictionaries | dictionary |
lexemes
---+--+---++--+-
blank | Space symbols| | {} | |
numword | Word, letters and digits | h1| {simple} | simple |
{h1}
blank | Space symbols| | {} | |
asciiword | Word, all ASCII | foo | {english_stem} | english_stem |
{foo}
blank | Space symbols| | {} | |
file | File or path name| /h1 | {simple} | simple |
{/h1}
blank | Space symbols| | {} | |
(7 rows)
What exactly *was* changed by this patch?
2007-11-19 21:25 adunstan
* doc/src/sgml/textsearch.sgml, src/backend/tsearch/wparser_def.c,
src/test/regress/expected/tsearch.out: Change descriptions of
entity and tag objects to XML entity and XML tag. Allow tag
and entity names that follow XML rules. Provide for hexadecimal as
well as decimal numeric entities. Adjust code names to coincide
with new descriptions.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] Open 8.3 issues
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have updated the patches queue with open 8.3 items: http://momjian.postgresql.org/cgi-bin/pgpatches Re: [DOCS] Normalized Ranking example incorrect in text search, Tom Lane This is done already. Re: [HACKERS] Heads up: 8.3beta3 to be wrapped this evening, andrew This too. [PATCHES] Proposed patch for ANALYZE overcounting dead rows, Tom Lane I think the consensus was to push this issue to 8.4. [PATCHES] [Fwd: Re: [HACKERS] Postgres 8.3 archive_command], Simon Riggs Applied. All updated. Re: [HACKERS] [PATCHES] Fixes for MONEY type using locale, Bruce Momjian Any feature additions to MONEY will be for 8.4. What is this doing in the 8.3 list? The email was: OK, so the big question then is if we are un-depricating this data type, does it have the behavior we want? (And the regression addition will be helpful too.) The point is if we are un-depricating the data type, do we want to do it with such limited usefulness? I am concerned it will get wider usage in 8.3 and therefore be harder to change. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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: [HACKERS] Open 8.3 issues
Greg Smith [EMAIL PROTECTED] writes: Sorry I didn't speak up before, I didn't think this was even a serious candidate for applying to 8.3. Seemed like too much of a functional change for slipping in this late and I presumed it was just going into the 8.4 queue. Changing the log level of a single message is hardly too much of a functional change to be considered during beta. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Open 8.3 issues
Bruce Momjian [EMAIL PROTECTED] writes: I have updated the patches queue with open 8.3 items: http://momjian.postgresql.org/cgi-bin/pgpatches Some other things that I think are open issues for 8.3: Poorly designed tsearch NOTICEs http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php psql -f error checking (or lack of it) http://archives.postgresql.org/pgsql-hackers/2007-11/msg00632.php Let select_common_type accept domains? http://archives.postgresql.org/pgsql-performance/2007-11/msg00280.php ltree bug #3720 http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php Windows/SSPI issue bug #3750 http://archives.postgresql.org/pgsql-bugs/2007-11/msg00184.php The first and last of these are certainly new-in-8.3 code. The others are pre-existing issues but I think they should be addressed. In particular, changing select_common_type()'s behavior seems like something that should only happen at a major release, since it's got at least some small chance of creating compatibility issues. The definition I was thinking of was if all the presented type OIDs are the same non-UNKNOWN type, just use that; else proceed with the existing algorithm. In many typical cases this would provide a bit of a speed boost, as well as allowing domain types to be selected. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open 8.3 issues
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Any feature additions to MONEY will be for 8.4. What is this doing in the 8.3 list? The point is if we are un-depricating the data type, do we want to do it with such limited usefulness? I am concerned it will get wider usage in 8.3 and therefore be harder to change. Well, we are certainly not re-opening feature development now, so it's not clear to me what you hope to accomplish. Are you proposing putting back the deprecation notice until you're satisfied that the type is complete? If so, what are the criteria for allowing it to be un-deprecated? I don't personally have a desire to ask for a bunch of new functionality to be added to MONEY. If any such thing happens, it should be driven by requests from actual users of the type, not by arbitrary criteria invented by people who aren't using it. 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
Re: [HACKERS] Open 8.3 issues
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Any feature additions to MONEY will be for 8.4. What is this doing in the 8.3 list? The point is if we are un-depricating the data type, do we want to do it with such limited usefulness? I am concerned it will get wider usage in 8.3 and therefore be harder to change. Well, we are certainly not re-opening feature development now, so it's not clear to me what you hope to accomplish. Are you proposing putting back the deprecation notice until you're satisfied that the type is complete? If so, what are the criteria for allowing it to be un-deprecated? I don't personally have a desire to ask for a bunch of new functionality to be added to MONEY. If any such thing happens, it should be driven by requests from actual users of the type, not by arbitrary criteria invented by people who aren't using it. It is a new problem so it is on the patches queue to see if anyone feels it is an 8.3 issue. If not, it will be moved to 8.4. You have already made your opinion clear. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open 8.3 issues
Tom Lane wrote:
I wrote:
Re: [HACKERS] Heads up: 8.3beta3 to be wrapped this evening, andrew
This too.
Uh, no, actually it isn't. I thought we were going to make cases
like h1 be treated as XML tags, but CVS HEAD fails to do that:
regression=# select * from ts_debug('h1foo/h1');
alias | description| token | dictionaries | dictionary | lexemes
---+--+---++--+-
blank | Space symbols| | {} | |
numword | Word, letters and digits | h1| {simple} | simple | {h1}
blank | Space symbols| | {} | |
asciiword | Word, all ASCII | foo | {english_stem} | english_stem | {foo}
blank | Space symbols| | {} | |
file | File or path name| /h1 | {simple} | simple | {/h1}
blank | Space symbols| | {} | |
(7 rows)
What exactly *was* changed by this patch?
2007-11-19 21:25 adunstan
* doc/src/sgml/textsearch.sgml, src/backend/tsearch/wparser_def.c,
src/test/regress/expected/tsearch.out: Change descriptions of
entity and tag objects to XML entity and XML tag. Allow tag
and entity names that follow XML rules. Provide for hexadecimal as
well as decimal numeric entities. Adjust code names to coincide
with new descriptions.
Oops. I will fix this in the morning when my brain is functioning. I see
what I did. I changed the rules for entity names but somehow missed
doing the same for tag names.
cheers
andrew
---(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
