SEO

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

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

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

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

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

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...0/msg00966.php

psql -f error checking (or lack of it)
http://archives.postgresql.org/pgsql...1/msg00632.php

Let select_common_type accept domains?
http://archives.postgresql.org/pgsql...1/msg00280.php

ltree bug #3720
http://archives.postgresql.org/pgsql...1/msg00044.php

Windows/SSPI issue bug #3750
http://archives.postgresql.org/pgsql...1/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