Re: Changeset Extraction v7.6.1

On 2014-02-24 12:50:03 -0500, Robert Haas wrote:
> On Mon, Feb 24, 2014 at 9:48 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2014-02-15 17:29:04 -0500, Robert Haas wrote:
> >> On Fri, Feb 14, 2014 at 4:55 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> >
> >> +       /*
> >> +        * XXX: It's impolite to ignore our argument and keep decoding until the
> >> +        * current position.
> >> +        */
> >>
> >> Eh, what?
> >
> > So, the background here is that I was thinking of allowing to specify a
> > limit for the number of returned rows. For the sql interface that sounds
> > like a good idea. I am just not so sure anymore that allowing to specify
> > a LSN as a limit is sufficient. Maybe simply allow to limit the number
> > of changes and check everytime a transaction has been replayed?
> 
> The last idea there seems like pretty sound, but ...
> 
> > It's all trivial codewise, I am just wondering about the interface most
> > users would want.
> 
> ...I can't swear it meets this criterion.

So, it's now:
CREATE OR REPLACE FUNCTION pg_logical_slot_get_changes(   IN slotname name, IN upto_lsn pg_lsn, IN upto_nchanges int,
VARIADICoptions text[] DEFAULT '{}',   OUT location pg_lsn, OUT xid xid, OUT data text)
 
RETURNS SETOF RECORD
LANGUAGE INTERNAL
VOLATILE ROWS 1000 COST 1000
AS 'pg_logical_slot_get_changes';

if nonnull upto_lsn allows limiting based on the lsn, similar with
upto_nchanges.

Makes sense?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services