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? It's all trivial codewise, I am just wondering about the interface most users would want. > + * We misuse the original meaning of SnapshotData's xip and > subxip fields > + * to make the more fitting for our needs. > [...] > + * XXX: Do we want extra fields instead of misusing existing > ones instead? > > If we're going to do this, then it surely needs to be documented in > snapshot.h. On the second question, you're not the first hacker to > want to abuse the meanings of the existing fields; SnapshotDirty > already does it. It's tempting to think we need a more principled > approach to this, like what we've done with Node i.e. typedef enum ... > SnapshotType; and then a separate struct definition for each kind, all > beginning with SnapshotType type. Hm, essentially that's what the ->satisfies pointer already is, right? There's already documentation of the extra fields in snapbuild, but I understand you'd rather have them moved? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
