Re: [HACKERS] Forcing current WAL file to be archived - Mailing list pgsql-patches

From Simon Riggs
Subject Re: [HACKERS] Forcing current WAL file to be archived
Date
Msg-id 1155665484.2649.155.camel@holly
Whole thread Raw
In response to Re: [HACKERS] Forcing current WAL file to be archived  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: [HACKERS] Forcing current WAL file to be archived  ("Jim C. Nasby" <jnasby@pervasive.com>)
List pgsql-patches
On Tue, 2006-08-15 at 12:13 -0500, Jim C. Nasby wrote:
> On Tue, Aug 15, 2006 at 06:07:12PM +0100, Simon Riggs wrote:
> > On Tue, 2006-08-15 at 11:10 -0400, Alvaro Herrera wrote:
> > > Simon Riggs wrote:
> > >
> > >
> > >
> > > > postgres=# select pg_xlogfile_name_offset(pg_switch_xlog());
> > > >       pg_xlogfile_name_offset
> > > > -----------------------------------
> > > >  000000010000000000000001 16777216
> > > > (1 row)
> > >
> > > > I've not taken up Jim Nasby's suggestion to make this an SRF with
> > > > multiple return rows/columns since that much complexity isn't justified
> > > > IMHO.
> > >
> > > Hum, but two columns here seem warranted, don't they?
> >
> > Maybe. People can write any function they like though, so I'm loathe to
> > agonize over this too much.
>
> True, but making people parse the output of a function to seperate the
> two fields seems pretty silly. Is there some reason why
> pg_xlogfile_name_offset shouldn't be a SRF, or use two out parameters?

If this makes a difference, then I'll do it. Does it make a difference?

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com


pgsql-patches by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: [HACKERS] Forcing current WAL file to be archived
Next
From: "Jim C. Nasby"
Date:
Subject: Re: [HACKERS] Forcing current WAL file to be archived