On Tue, Feb 2, 2010 at 22:50, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
>>> Alex Hunsaker writes:
Yeah the both is gross. How about:
plperl.on_plperl_init
plperl.on_plperlu_init
plperl.on_init ?
>> Well its already in.
>
> Wel
Fujii Masao wrote:
> On Thu, Jan 14, 2010 at 7:04 PM, Heikki Linnakangas
> wrote:
>> 1. Walsender calls pq_wait() which calls select(), waiting for timeout,
>> or data to become available for reading in the underlying socket.
>>
>> 2. Client issues an SSL renegotiation by sending a message to the
On Wednesday, February 3, 2010, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
>>> Alex Hunsaker writes:
Yeah the both is gross. How about:
plperl.on_plperl_init
plperl.on_plperlu_init
plperl.on_init ?
>>>
>>> I like the first two.
Alex Hunsaker writes:
> On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
>> Alex Hunsaker writes:
>>> Yeah the both is gross. Â How about:
>>> plperl.on_plperl_init
>>> plperl.on_plperlu_init
>>> plperl.on_init ?
>>
>> I like the first two. Â The problem of selecting a good name for the
>> third o
On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
> Alex Hunsaker writes:
>> Yeah the both is gross. How about:
>> plperl.on_plperl_init
>> plperl.on_plperlu_init
>> plperl.on_init ?
>
> I like the first two. The problem of selecting a good name for the
> third one is easily solved: don't have it.
Alex Hunsaker writes:
> Yeah the both is gross. How about:
> plperl.on_plperl_init
> plperl.on_plperlu_init
> plperl.on_init ?
I like the first two. The problem of selecting a good name for the
third one is easily solved: don't have it. What would it be except
a headache and a likely security
On Thu, Jan 14, 2010 at 7:04 PM, Heikki Linnakangas
wrote:
> 1. Walsender calls pq_wait() which calls select(), waiting for timeout,
> or data to become available for reading in the underlying socket.
>
> 2. Client issues an SSL renegotiation by sending a message to the server
>
> 3. Server receiv
On Tue, Feb 2, 2010 at 20:46, Robert Haas wrote:
> On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas wrote:
>> On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker wrote:
>>> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
This is an update the fourth of the patches to be split out from the
form
On Tue, Feb 2, 2010 at 10:51 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas wrote:
>> > On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker wrote:
>> >> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>> >>> This is an update the fourth of the patch
Robert Haas escribió:
> On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas wrote:
> > On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker wrote:
> >> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
> >>> This is an update the fourth of the patches to be split out from the
> >>> former 'plperl feature patch
On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas wrote:
> On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker wrote:
>> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>>> This is an update the fourth of the patches to be split out from the
>>> former 'plperl feature patch 1'.
>>>
>>> Changes in this pat
On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker wrote:
> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>> This is an update the fourth of the patches to be split out from the
>> former 'plperl feature patch 1'.
>>
>> Changes in this patch:
>>
>> - Adds plperl.on_trusted_init and plperl.on_untrus
On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
> This is an update the fourth of the patches to be split out from the
> former 'plperl feature patch 1'.
>
> Changes in this patch:
>
> - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
> on_trusted_init is PGC_USERSET, on_untrusted
Robert Haas writes:
> On Sat, Jan 30, 2010 at 1:12 AM, Oleg Bartunov wrote:
>> I made available test data I used on
>> http://www.sai.msu.su/~megera/wiki/2009-07-27,
>> so anyone can reproduce my results. You can download data
>> http://www.sai.msu.su/~megera/postgres/files/links2.sql.gz, it's bi
On Wed, 2010-02-03 at 00:10 +0100, Joachim Wieland wrote:
> I admit that it was not clear what I meant. The comment should only
> address LISTEN / NOTIFY on the standby server. Do you see any problems
> allowing it?
The original comment was a part of the NotifyStmt case, and I don't
think we can s
On Sat, Jan 30, 2010 at 1:12 AM, Oleg Bartunov wrote:
> I made available test data I used on
> http://www.sai.msu.su/~megera/wiki/2009-07-27,
> so anyone can reproduce my results. You can download data
> http://www.sai.msu.su/~megera/postgres/files/links2.sql.gz, it's big (580Mb)
Ugh. My system
(2010/02/02 23:50), Robert Haas wrote:
> 2010/2/1 KaiGai Kohei:
>>> I'm making a general statement - if something is BROKEN (like the
>>> rename case we just dealt with), we should look at fixing it. If it's
>>> just something that could be cleaned up or done more nicely, we should
>>> leave it al
Dave Page wrote:
> On Tue, Feb 2, 2010 at 8:20 PM, Bruce Momjian wrote:
> >> > Seems we either have to contact the author or rewrite the file.
> >>
> >> Why? Even if the text is removed, he will still own the copyright, as
> >> is the case for any patch submitted because we don't have any form of
On Tue, Feb 2, 2010 at 8:20 PM, Bruce Momjian wrote:
>> > Seems we either have to contact the author or rewrite the file.
>>
>> Why? Even if the text is removed, he will still own the copyright, as
>> is the case for any patch submitted because we don't have any form of
>> copyright assignment.
>
Dave Page wrote:
> On Tue, Feb 2, 2010 at 6:48 PM, Bruce Momjian wrote:
>
> > The intagg copyright is on a _Makefile_:
> >
> > ? ? ? ?# Makefile for integer aggregator
> > ? ? ? ?# Copyright (C) 2001 Digital Music Network.
> > ? ? ? ?# by Mark L. Woodward
> > ? ? ? ?# $PostgreSQL: pgsql/contrib/i
On Tue, Feb 2, 2010 at 6:48 PM, Bruce Momjian wrote:
> The intagg copyright is on a _Makefile_:
>
> # Makefile for integer aggregator
> # Copyright (C) 2001 Digital Music Network.
> # by Mark L. Woodward
> # $PostgreSQL: pgsql/contrib/intagg/Makefile,v 1.10 2008/11/14
Greg Stark wrote:
> So based on our discussion of last week my understanding is that as long as
> these people are content to release the code under the same license then
> these statements don't change anything since they're included in the
> Postgresql global development group anyways.
Yes, I be
Bruce Momjian wrote:
>
> I received permission from Andrew Yu to remove a copyright he had on
> another file in 2007:
>
> http://archives.postgresql.org/pgsql-hackers/2007-03/msg01528.php
>
> I have emailed him to get approval to remove this mention also.
I received an email reply from An
2010/2/2 Teodor Sigaev :
>>> > With perhaps some minor tweaks to some of the names and a rework of
>>> > the else
>>> > clause in ginInsertEntry(), I feel this patch is reasonably close to
>>> > commit.
>>
>> Yeah, I think it can get there, but only if Oleg and Teodor provide an
>> updated versio
So based on our discussion of last week my understanding is that as long as
these people are content to release the code under the same license then
these statements don't change anything since they're included in the
Postgresql global development group anyways.
greg
On 2 Feb 2010 19:39, "Bruce M
> With perhaps some minor tweaks to some of the names and a rework of the else
> clause in ginInsertEntry(), I feel this patch is reasonably close to commit.
Yeah, I think it can get there, but only if Oleg and Teodor provide an
updated version pretty soon...
Updated version of patch based o
On Tue, Feb 2, 2010 at 2:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> Hmm, in that case, I think the problem is that this function has no
>> comment explaining its intended charter.
>
> That's certainly a big problem, but a comment won't fix the fact that
> the name is misleading. We need bot
Robert Haas writes:
> Hmm, in that case, I think the problem is that this function has no
> comment explaining its intended charter.
That's certainly a big problem, but a comment won't fix the fact that
the name is misleading. We need both a comment and a name change.
re
On Fri, Jan 29, 2010 at 1:56 PM, Greg Stark wrote:
> On Tue, Jan 19, 2010 at 3:25 PM, Tom Lane wrote:
>> That function *seriously* needs documentation, in particular the fact
>> that it's a no-op on machines without the right kernel call. The name
>> you've chosen is very bad for those semantics
On sön, 2010-01-31 at 09:34 +0100, Guillaume Lelarge wrote:
> I worked on a patch to make PostgreSQL binaries use the new
> PQconnectdbParams() libpq functions.
Can someone dig out the patch that Heikki had started to support psql
automatically setting the client encoding? I think that's what sta
2010/2/1 Magnus Hagander :
> 2010/1/28 Magnus Hagander :
>> On Thu, Jan 28, 2010 at 21:16, Tom Lane wrote:
>>> Magnus Hagander writes:
On Thu, Jan 28, 2010 at 17:16, Tom Lane wrote:
> However, now that I know the real issue is you're using inet_addr, I
> would like to know why you'r
I wrote:
> After tracing through it, the problem is that rebuild_relation() assumes
> toast tables are always in PG_TOAST_NAMESPACE; which has not been true
> since 8.3. CLUSTER has been renaming temp toast tables into the wrong
> namespace right along. Without the assert to call attention to it,
Some more _personalized_ copyright noticed have crept into our source
tree:
/src/tutorial/basics.sourceCopyright (c) 1994, Andrew Yu, University of
California
/contrib/intagg/Makefile Copyright (c) 2001 Digital Music Network by
Mark L. Woodward
/src/port/rint.c Copyri
On Tuesday 02 February 2010 20:06:32 Robert Haas wrote:
> On Tue, Feb 2, 2010 at 1:34 PM, Andres Freund wrote:
> > For now it could - but it very well might be converted to sync_file_range
> > or similar, which would have different "sideeffects".
> >
> > As the potential code duplication is rathe
On Tue, Feb 2, 2010 at 1:34 PM, Andres Freund wrote:
> For now it could - but it very well might be converted to sync_file_range or
> similar, which would have different "sideeffects".
>
> As the potential code duplication is rather small I would prefer to describe
> the prime effect not the sidee
I wrote:
> Takahiro Itagaki writes:
>> AFAICS, the assertion is broken, but the code is correct. We just need to
>> adjust the expression in the assertion.
> I think this is 100% wrong. Toast tables shouldn't be changing
> namespace either; which means you broke something somewhere else.
After
On Mon, Feb 01, 2010 at 07:53:05PM -0700, Alex Hunsaker wrote:
> On Mon, Feb 1, 2010 at 03:58, Tim Bunce wrote:
> > On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote:
> >
> >> plc_safe_ok.pl seems to loose its CVS $PostgreSQL$ keyword.
> >Probably a slip-up when I merged the changes fr
On Tuesday 02 February 2010 19:14:40 Robert Haas wrote:
> On Tue, Feb 2, 2010 at 12:50 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> On Tuesday 02 February 2010 18:36:12 Robert Haas wrote:
> >>> I took a look at this patch today and I agree with Tom that
> >>> pg_fsync_start() is a very conf
Simon Riggs wrote:
> On Fri, 2010-01-29 at 15:01 +, Simon Riggs wrote:
>
>> Putting it back takes time and
>> given enough of that rare cloth, it will eventually be put back.
>
> Looks like I'll have time to add the starts-at-shutdown-checkpoint item
> back in after all.
Great! Thank you, mu
On Tue, Feb 2, 2010 at 12:50 PM, Tom Lane wrote:
> Andres Freund writes:
>> On Tuesday 02 February 2010 18:36:12 Robert Haas wrote:
>>> I took a look at this patch today and I agree with Tom that
>>> pg_fsync_start() is a very confusing name. I don't know what the
>>> right name is, but this doe
On Tuesday 02 February 2010 18:36:12 Robert Haas wrote:
> On Fri, Jan 29, 2010 at 1:56 PM, Greg Stark wrote:
> > On Tue, Jan 19, 2010 at 3:25 PM, Tom Lane wrote:
> >> That function *seriously* needs documentation, in particular the fact
> >> that it's a no-op on machines without the right kernel
Andres Freund writes:
> On Tuesday 02 February 2010 18:36:12 Robert Haas wrote:
>> I took a look at this patch today and I agree with Tom that
>> pg_fsync_start() is a very confusing name. I don't know what the
>> right name is, but this doesn't fsync so I don't think it shuld have
>> fsync in th
Takahiro Itagaki writes:
> AFAICS, the assertion is broken, but the code is correct. We just need to
> adjust the expression in the assertion.
I think this is 100% wrong. Toast tables shouldn't be changing
namespace either; which means you broke something somewhere else.
Jesper Krogh wrote:
> Ultimately I would like an infinite amount of configurabillity
There was some discussion of this previously. I was thinking of
doing something with it, but Laurent indicated off-list he was
working on it, so I left it to him. Besides reading these threads,
you might wa
On Tue, Feb 02, 2010 at 03:34:24PM +0100, Boszormenyi Zoltan wrote:
> Here's the new patch with the updated regression test.
Committed. Thanks a lot.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|P
2010/2/1 KaiGai Kohei :
>> I'm making a general statement - if something is BROKEN (like the
>> rename case we just dealt with), we should look at fixing it. If it's
>> just something that could be cleaned up or done more nicely, we should
>> leave it alone for now.
>
> OK, Please forget the secon
Michael Meskes írta:
> On Sat, Jan 30, 2010 at 11:09:34AM +0100, Boszormenyi Zoltan wrote:
>
>> After I sent it and reread my mail, I realized that my fix
>> wouldn't be enough because of the above: ECPG uses sprintf()
>> for float and double, and just like in the backend, a common
>> code to se
On Sat, Jan 30, 2010 at 11:09:34AM +0100, Boszormenyi Zoltan wrote:
> After I sent it and reread my mail, I realized that my fix
> wouldn't be enough because of the above: ECPG uses sprintf()
> for float and double, and just like in the backend, a common
> code to send "NaN" and +/- "Infinity" to t
Mark Mielke wrote:
> On 01/29/2010 09:01 PM, Tom Lane wrote:
> > Maybe. We concluded in the April 2009 thread that
> > standard_conforming_strings = ON had gotten little or no field testing,
> > and I don't see any strong reason to hope that it's gotten much more
> > since then.
>
> Not to contra
Robert Haas írta:
> 2010/1/12 Boszormenyi Zoltan :
>
>> Tom Lane írta:
>>
>>> Alvaro Herrera writes:
>>>
>>>
But it would be broken in very obvious ways, no? It's not like it would
be silently broken and thus escape testing ...
>>> Well, if we wanted to
50 matches
Mail list logo
