On Thu, Feb 27, 2014 at 11:06 AM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2014-02-24 12:50:03 -0500, Robert Haas wrote: >> On Mon, Feb 24, 2014 at 9:48 AM, Andres Freund <and...@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 <and...@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, VARIADIC > options 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?
Time will tell, but it seems plausible to me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers