Обсуждение: 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On 11/24/07, Bruce Momjian <bruce@momjian.us> 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
Marko Kreen wrote: > On 11/24/07, Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> 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
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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
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('<h1>foo</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
descriptionsofentity and tag objects to "XML entity" and "XML tag". Allow tagand entity names that follow XML rules.
Providefor hexadecimal aswell as decimal numeric entities. Adjust code names to coincidewith new descriptions.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Greg Smith <gsmith@gregsmith.com> 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
Bruce Momjian <bruce@momjian.us> 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
Bruce Momjian <bruce@momjian.us> 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
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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('<h1>foo</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
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