Hi!
contrib/spi has a Makefile that uses $(addsuffix) makefile rules for
DATA_built and DOCS. It's the only Makefile in contrib that does it.
I would like to change that to actually listing the modules instead. The
reason for that is that parsing the Makefile for the msvc build will be a
*lot*
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Not really, but maybe it would be sensible to reset last_pgstat_start_time
when doing a database-wide restart?
You mean like this, attached?
I'd be fairly surprised if resetting the variable in the child process
Magnus Hagander [EMAIL PROTECTED] writes:
contrib/spi has a Makefile that uses $(addsuffix) makefile rules for
DATA_built and DOCS. It's the only Makefile in contrib that does it.
I would like to change that to actually listing the modules instead.
This seems like a definite regression in
Zdenek Kotala [EMAIL PROTECTED] writes:
This patch brings possibility to switch from default build-in timezone
to another timezone source - typically to OS timezone location.
It was discussed few weeks ago:
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php
AFAIR, the
Magnus Hagander wrote:
I would like to change that to actually listing the modules instead.
The reason for that is that parsing the Makefile for the msvc build
will be a *lot* easier if I don't have to parse $addsuffix rules.
Let's not open that can of worms. Even if you think it's only a
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
This patch brings possibility to switch from default build-in timezone
to another timezone source - typically to OS timezone location.
It was discussed few weeks ago:
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane wrote:
I certainly don't see the point of the implementation as you have it
--- it adds a great deal of unnecessary infrastructure compared to just
installing a symlink at share/postgresql/timezone.
The point of my solution is that all
Magnus Hagander wrote:
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
This patch brings possibility to switch from default build-in timezone
to another timezone source - typically to OS timezone location.
It was discussed few weeks ago:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I found LIKE operators are slower on multi-byte encoding databases
than single-byte encoding ones. It comes from difference between
MatchText() and MBMatchText().
We've had an optimization for single-byte encodings using
Mark Stosberg wrote:
Bruce Momjian wrote:
Mark Stosberg wrote:
It woud also be nice to document that the full names custom and tar are
supported. Longer names can be nice for clarity.
( Unfortunately, wrong formats like txx also work instead of throwing
an error. )
I don't see
Applied. I did the case where we exit right away too, just for
consistency.
---
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Not really, but maybe it would be
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Ühel kenal päeval, N, 2007-03-22 kell 11:08, kirjutas Tom Lane:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I found LIKE operators are slower on multi-byte encoding databases
than single-byte encoding ones. It comes from difference between
MatchText() and MBMatchText().
We've had an
Patch applied.
Please provide a documentation addition. Thanks.
---
Nikolay Samokhvalov wrote:
On 3/4/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
I'll fix these issues and extend the patch with resgression tests
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Bruce Momjian [EMAIL PROTECTED] writes:
Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
append and file too.
Surely these should all be pg_strcasecmp?
regards, tom lane
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
append and file too.
Surely these should all be pg_strcasecmp?
Yep, fixed.
--
Bruce Momjian
Applying newest version of this patch now; still needs documentation.
---
Nikolay Samokhvalov wrote:
On 3/5/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
On 3/4/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Bruce Momjian wrote:
Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
append and file too.
Append is undocumented as it's intended to be used by pg_dumpall, not
directly by users.
Regards, Dave.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Will use '16' rather than '100'.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Dave Page wrote:
Bruce Momjian wrote:
Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
append and file too.
Append is undocumented as it's intended to be used by pg_dumpall, not
directly by users.
Bruce Momjian wrote:
Dave Page wrote:
Bruce Momjian wrote:
Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
append and file too.
Append is undocumented as it's intended to be used by pg_dumpall, not
Nikolay Samokhvalov wrote:
Here is a new version of the patch. I didn't change any part of docs
yet. Since there were no objections I've changed the name of the
function to xmlpath().
I didn't see any discussion about changing the name to xmlpath. Seeing
that the function implements xpath,
Bruce Momjian wrote:
Patch applied.
This code seems to think that if an xml datum starts with ?xml it's a
document. That is completely bogus.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 6: explain
Nikolay Samokhvalov wrote:
On 3/4/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
I'll fix these issues and extend the patch with resgression tests
and docs for xpath_array(). I'll resubmit it very soon.
Here is a new version of the patch. I didn't change any part of docs
yet. Since there
Nikolay Samokhvalov wrote:
Also, maybe someone can suggest better approach for passing namespace
bindings (more convenient than ARRAY[ARRAY[...], ARRAY[...]])?
Your code assumes
ARRAY[ARRAY['myns', 'myns2'], ARRAY['http://example.com',
'http://example2.com']]
Shouldn't it be
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
reviews and approves it.
I was hoping that we're deprecating contrib/xml2, so I
Peter Eisentraut wrote:
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
reviews and approves it.
I was hoping that we're
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Bruce Momjian wrote:
Peter Eisentraut wrote:
I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
features to it.
Author states:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production instances will be unable (or,
in
Bruce Momjian [EMAIL PROTECTED] writes:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
This patch was already objected to, on
Dave Page wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
features to it.
Author states:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
This patch was
On 3/22/07, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
features to it.
Author states:
I understand that XML support is planned and at least partially
On Thu, 2007-03-22 at 16:43 -0400, Bruce Momjian wrote:
Will use '16' rather than '100'.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Did Greg push a version which didn't carry the WIP
Alvaro Herrera wrote:
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Did Greg push a version
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Mike Rylander wrote:
A related question, however: Will the XML features being included in
8.3 support namespace prefix registration?
That is certainly the plan.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
On Thu, Mar 22, 2007 at 04:58:09PM -0400, Bruce Momjian wrote:
Is there a new version of this patch being worked on?
Yes, I will submit a new version next week.
Joachim
---(end of broadcast)---
TIP 5: don't forget to increase your free space
Peter Eisentraut wrote:
Mike Rylander wrote:
A related question, however: Will the XML features being included in
8.3 support namespace prefix registration?
That is certainly the plan.
Let me bounce my ostrich (sp?) head up here and say, thanks for your
work on this Peter.
Joshua D. Drake
Folks,
Here is the latest version of Load distributed checkpoint patch.
I've fixed some bugs, including in cases of missing file errors
and overlapping of asynchronous checkpoint requests.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
checkpoint_v3.patch.gz
Description: Binary
Hello,
I found wrong definitions of max bytes for a char in
EUC_CN (3-2), EUC_TW (3-4) and MULE_INTERNAL (3-4).
Especially, EUC_TW and MULE_INTERNAL might cause problems.
Their pg_*_mblen could have returned values larger than their maxmblen.
I'm worrying that it leads buffer overrun.
Index:
ITAGAKI Takahiro [EMAIL PROTECTED] wrote:
I found wrong definitions of max bytes for a char in
EUC_CN (3-2), EUC_TW (3-4) and MULE_INTERNAL (3-4).
Also, the length of a char in GB18030 could be 4,
though GB18030 is not supported as a server encoding.
- {0, pg_gb18030_mblen,
I have applied the following cleanup to procarray.c.
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index:
50 matches
Mail list logo
