Open 8.3 issues

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 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

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