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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings

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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly