On Thu, Feb 27, 2014 at 11:06 AM, Andres Freund <andres@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 <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, 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
