Re: [HACKERS] Re: ORDBMS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: Chris Bitmead <chris(at)bitmead(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: ORDBMS
Date: 2000-01-28 15:08:16
Message-ID: 10717.949072096@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The Hermit Hacker <scrappy(at)hub(dot)org> writes:
>> What I don't understand yet is whether the contents of table
>> "address" have any connection to the data stored in table "person".
>> If not, why must I create a table in order to define a datatype? Seems
>> like a separate CREATE DATATYPE command would make more sense...

> Not quite an answer to your question, but my guess is that 'address
> ADDRESS' would contain a pointer (OID) to the address table ... so the
> person table would be realtively small in comparison to the address table
> ...
> The way I look at the above, its a 'JOIN' at table create time, based on a
> unique value, the OID ...

Hmm. OK, that makes sense, because I know I've seen places in the code
that think that any "set type" is represented as an OID. I never
understood what that was all about, but in this context that would be
what would happen. Assuming that this facility is the same as what
the code calls a set, that is.

So, if I looked into table address, presumably I'd find rows
corresponding to each value that is (ever has been?) stored in another
table with an ADDRESS column. How do no-longer-useful values get
cleaned out of the address table, do you suppose?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2000-01-28 15:25:36 Re: [HACKERS] [6.5.3] 'attribute not found'
Previous Message The Hermit Hacker 2000-01-28 15:02:32 Re: [HACKERS] Re: ORDBMS