Skip site navigation (1) Skip section navigation (2)

Moving snapshot code around

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Pg Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Moving snapshot code around
Date: 2008-03-18 19:19:40
Message-ID: (view raw or whole thread)
Lists: pgsql-patches

I'm playing with the snapshot code to create a new module to stash used
snapshots and refcount them.

It occured to me that a first easy step is to separate the relevant code
from tqual.c into a new file, snapshot.c, and split tqual.h in two
creating snapshot.h.  Basically the internals of snapshots are now in
tqual.c/h, and the external interface is snapshot.c/h.

The nice thing about it is that most users of snapshots only need the
external interface, so most details can remain behind tqual.h which is
now a seldom-included header.  (The bad news is that the widely used
heapam.h still has to include it, because it needs the HTSU_Result
enum, so tqual.h is still indirectly included in a lot of places.
I think I can easily move the enum definition to snapshot.h but it seems

So here's a patch to do this.  It just moves code around -- there's no
extra functionality here.

The other approach, of course, is to just keep all the code in tqual.c
and not create a separate module at all.  Opinions?  I prefer to keep
them separate, but I'm not wedded to it if there's any strong reason not
to do it.  Also, the line is currently blurred because some users of
snapshots mess with the internals directly (setting snapshot->curcid),
but we could clean that up and make it so that those become external
interface users too.

Alvaro Herrera                      
The PostgreSQL Company - Command Prompt, Inc.

Attachment: snapshot.patch
Description: text/x-diff (17.9 KB)


pgsql-patches by date

Next:From: Tom LaneDate: 2008-03-18 22:05:29
Subject: Re: Patch to inline stable SQL set returning UDFs
Previous:From: Bruce MomjianDate: 2008-03-18 18:41:24
Subject: Re: Proposal for Null Bitmap Optimization(for Trailing NULLs)

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group