Hello Clark,
Tuesday, July 06, 1999 you wrote:
C> (look of puzzlement) Where did I go wrong with what
C> you are proposing? I'm not trying to invent my
C> own scheme... I'm trying to understand yours.
Ok. If American people wants to know the True Path, it
can be enlightened :))) (it's a joke)
So what's exactly proposed:
Introduction of what will seem a new data type in table
structure:
CREATE TABLE atable (a int4)
CREATE TABLE btable (b int4, c link (atable)) - "link" looks like
new data type.
Example query with link:
SELECT * FROM atable where btable.b < 5 AND btable.c = atable.tid
(or here should go ctid - you can know better)
Type checking:
CREATE TABLE ctable (d int4)
SELECT * FROM ctable where btable.b < 5 AND btable.c = ctable.tid -
it should produce an error because link isn't to ctable.
No additional constraint is placed. Tables can reference one
another in any combination, maybe the table should be able
to reference itself.
How all that is implemented:
As we have seen, link is matched against tid in queries. It
means that link internally can be of the same data type as tid.
MVCC stuff: as Vadim pointed out, updated tuples are chained
already, so this feature can naturally be utilized. Referencing
tuple is always pointing to the oldest version of foreign
updated tuple. If transaction needs the version of foreign
tuple other than oldest, it follows the chain.
Vacuuming removes these chains thus packing the table and
rewriting references to vacuumed table in other tables.
Vacuuming thus needs high priority, maybe lock on the table
being vacuumed and all referencing tables.
Since referencing fields are rewritten only during vacuum,
there is no need of indices on any field.
Best regards, Leon
