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* ea
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
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
This patch brings possibility to switch from default build-in timezone
to another timezone source - typically to OS timezone location. This
enhancement helps to packagers easy solve integration problem with
systems Timezones.
If --with-tzdir=/usr/share/zoneinfo is specified as ./configure
p
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 co
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 s
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/msg
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 al
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:
http://archives.postgresql.org/pgsql-hackers/2
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
> pg_database_encoding_
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
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 woul
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.
---
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
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 te
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.
---
Mi
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.
--
B
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.
---
Gr
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.
---
Gr
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
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_d
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 "http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 6: explain analyze is your friend
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. Si
Andrew Dunstan wrote:
> Would it be better to use some more unlikely name for the dummy root
> element used to process fragments than ?
Why do we even need to support xpath on fragments?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)-
Is there a new version of this patch being worked on?
---
Tom Lane wrote:
> Joachim Wieland <[EMAIL PROTECTED]> writes:
> > On Tue, Mar 13, 2007 at 11:52:38AM -0400, Tom Lane wrote:
> >> Why do you need to tell that? IMHO,
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
ARRAY[ARRAY['m
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,
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 ho
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.
---
Pa
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 unab
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,
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 man
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 pa
Patch removed from patch queue.
---
Pavel Stehule wrote:
>
> >"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > > this patch contains function ArmorCustomVariables. This function set
> >flag
> > > armored on any custom varia
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
>> implemented for 8.3, but many production insta
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 revie
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.
---
Je
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
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 Gre
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.
---
Si
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.
---
Si
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.
---
Si
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 broadcast)---
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 m
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.
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, pg_gb
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: src/backend/storage/ipc/procarray
56 matches
Mail list logo
