Adding a field to each tuple
Ok,
I decided to learn more about postgresql.
My challenge:
Given an oid, efficiently determine the most derived class the instance
belongs to.
My intended solution is to add an extra attribute to each tuple
which contains the oid of the most derived class it belongs to.
On inserting a tuple I set this field to the value of the table/class used
for the
insert.
Using with a negative index I can allways retreive the oid of
the most derived class.
How to proceed?
Step: 1
Add the new field to the HeapTupleData struct in htup.h.
Step: 2
Modify inserting function to add the oid of the class into which
the insertion takes place.
Step 3
???
Step 4
Can anyone give clues as whatelse I will have to do to get this to work?
Thanks,
Maurice
Ok,
I decided to learn more about postgresql.
My challenge:
Given an oid, efficiently determine the most derived class the instance
belongs to.My intended solution is to add an extra attribute to each tuple
which contains the oid of the most derived class it belongs to.
This is a lot of overhead for places it is not needed.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
-----Original Message-----
From: Bruce Momjian <maillist@candle.pha.pa.us>
To: Maurice Gittens <mgittens@gits.nl>
Cc: hackers@postgreSQL.org <hackers@postgreSQL.org>
Date: donderdag 26 februari 1998 2:09
Subject: Re: [HACKERS] Adding a field to each tuple
My challenge:
Given an oid, efficiently determine the most derived class the instance
belongs to.My intended solution is to add an extra attribute to each tuple
which contains the oid of the most derived class it belongs to.
I expect it will also introduce me to quite a few aspects of the postgresql
system.
If I'm going to learn about the system then I might as well get a good
overall
view of how things are organized.
Sure I've read parts of the developers manual but I think this little
project will let
me see (in the source) how information travels from diskstorage all the
way to the client.
Also valuable information on how to debug the backend etc. will be
learned in this way I think.
While trying to fix a large_object memory leak I noticed
that without an understanding of how the many components interrelate
it's almost impossible to fix anything because you don't know who is
responsible for what.
I certainly do appreciate any help I can get.
This is a lot of overhead for places it is not needed.
Any suggestions for solving the general given problem with less overhead?-:)
Best regards,
Maurice
Import Notes
Resolved by subject fallback
I certainly do appreciate any help I can get.
This is a lot of overhead for places it is not needed.
Any suggestions for solving the general given problem with less overhead?-:)
Yes, this is a natural use for a trigger. Create the column in the base
table, and have it stuff the value on insert. You have to make the
trigger on each derived table, but you may be able to use the same
trigger on all tables. This is how we are implementing time travel.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
-----Original Message-----
From: Bruce Momjian <maillist@candle.pha.pa.us>
To: Maurice Gittens <mgittens@gits.nl>
Cc: hackers@postgreSQL.org <hackers@postgreSQL.org>
Date: donderdag 26 februari 1998 21:36
Subject: Re: [HACKERS] Adding a field to each tuple
Yes, this is a natural use for a trigger. Create the column in the base
table, and have it stuff the value on insert. You have to make the
trigger on each derived table, but you may be able to use the same
trigger on all tables. This is how we are implementing time travel.
Agreed. This was my first try. But doesn't solve the general problem, of
mapping an arbitrary valid (within the system) OID to the OID of it's class
does it ?!.
So I've started hacking and I'm now encountering my first problems -:).
(I do realize that I going to run into more trouble for large objects.)
Learning new stuff is so much fun -:).
Thanks,
Maurice (who's enjoying himself today.)
Import Notes
Resolved by subject fallback