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
