Bruce Momjian wrote:
Euler, have you updated this patch yet?
Here is an updated patch. It follows the Oracle behaviour and uses a
cache mechanism to avoid calling setlocale() all the time. I unified the
localized_* and str_* functions. I didn't test it on Windows. I would
appreciate some fe
Joshua D. Drake wrote:
> On Wed, 23 Apr 2008 14:41:20 -0700
> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> Per final discussion here:
>
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg01607.php
Isn't this going to mean \g is listed twice?
+ fprintf(output, _(
2008/4/23 Alvaro Herrera <[EMAIL PROTECTED]>:
> H.Harada escribió:
>
>
> > # This is my first time to send a patch. If I did something wrong, I
> > appreciate your pointing me out.
>
> Brace positioning is off w.r.t. our conventions -- please fix that and
> resubmit.
Here's updated version. Th
On Wed, 23 Apr 2008 14:41:20 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
Hello,
Per final discussion here:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01607.php
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Confer
Hello,
As discussed:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01476.php
The patch does the following:
Adds an Execution line to the \? output.
Changes the help output in mainloop.c to be more useful.
Greatly reduces overall default banner output:
* shows client version and type
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> I think the messages should not have a newline in the middle.
> Are you talking about the one in pg_ctl? We have other messages in
> pg_ctl that already do this, so I figured it was ok there...
I concur that the messages added
Alvaro Herrera wrote:
> FWIW I noticed yesterday after going to bed that SnapshotContext serves
> no useful purpose -- we can just remove it and store snaps in
> TopTransactionContext.
... which is what the attached patch does.
--
Alvaro Herrerahttp://www.Command
Alvaro Herrera wrote:
> I think the messages should not have a newline in the middle.
>
> Also, I am wondering if in PM_WAIT_BACKUP mode we should accept new
> connections from superusers only.
I spent some thought on that.
You'd need to wait until the user is authenticated before you can determi
Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
> > Applied with some minor changes to the error messages to make them
> > closer to our guidelines. (With my track record, it's not entirely
> > unlikely that someone will fix them further though :-P)
>
> I think the messages should not have a new
Magnus Hagander wrote:
> Applied with some minor changes to the error messages to make them
> closer to our guidelines. (With my track record, it's not entirely
> unlikely that someone will fix them further though :-P)
I think the messages should not have a newline in the middle.
Also, I am wond
H.Harada escribió:
> # This is my first time to send a patch. If I did something wrong, I
> appreciate your pointing me out.
Brace positioning is off w.r.t. our conventions -- please fix that and
resubmit.
I have added this patch to the May commitfest.
--
Alvaro Herrera
Albe Laurenz wrote:
> Magnus Hagander wrote:
> > This doesn't look like our normal coding standards, and should
> > probably be changed:
> > + if (0 != stat(BACKUP_LABEL_FILE, &stat_buf))
> >
> > (there's a number of similar places)
>
> I see. Lacking guidelines, I now copied how stat(2) is use
Simon Riggs wrote:
> Forgive me for being dense, but what is there to stop you using a
> CopySnapshot in TopMemoryContext? If you did, there would be no way to
> free it, nor would we notice it had been done, AFAICS. Not anything I'm
> thinking about doing, though.
Well, TopMemoryContext is no go
On Wed, 2008-04-23 at 08:21 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Tue, 2008-04-22 at 18:13 -0400, Alvaro Herrera wrote:
> > > Simon Riggs wrote:
> > >
> > > > OK, so it can;t be copied to a longer lived memory context?
> > >
> > > If you need that ability, please explain.
> >
Tom Lane wrote:
> The only reason we have memory contexts at all is to avoid the need to
> track individual palloc'd objects. Since we're instituting exactly such
> tracking for snapshots, there's no value in placing them in
> general-purpose memory contexts.
FWIW I noticed yesterday after going
Simon Riggs wrote:
> On Tue, 2008-04-22 at 18:13 -0400, Alvaro Herrera wrote:
> > Simon Riggs wrote:
> >
> > > OK, so it can;t be copied to a longer lived memory context?
> >
> > If you need that ability, please explain.
>
> No, I wish to prevent that, not enable it.
I see. Sure, we don't have
out.
Hitoshi Harada
generate_series_timestamp.20080423.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Albe Laurenz wrote:
> Magnus Hagander wrote:
> > This doesn't look like our normal coding standards, and should
> > probably be changed:
> > + if (0 != stat(BACKUP_LABEL_FILE, &stat_buf))
> >
> > (there's a number of similar places)
>
> I see. Lacking guidelines, I now copied how stat(2) is use
Magnus Hagander wrote:
> This doesn't look like our normal coding standards, and should probably
> be changed:
> + if (0 != stat(BACKUP_LABEL_FILE, &stat_buf))
>
> (there's a number of similar places)
Lacking guidelines, I now tried to copy how stat(2) is used in other parts
of the code.
You
On Tue, 2008-04-22 at 18:13 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > OK, so it can;t be copied to a longer lived memory context?
>
> CopySnapshot always copies snapshots to SnapshotContext, which is a
> context that lives until transaction end. There's no mechanism for
> copying a
20 matches
Mail list logo
