Aasmund,
Thank you for the clarification. Now that I know what you are doing, I
went through exactly the same thing about a year ago ... which is how we
discovered some additional problems with using OIDs in database design.
I was trying to spare you the same dead end.
> > If your problem is that you want to update VIEWs and aren't sure
> what the
> > PK for the view is, could you follow a standard like this:
> >
> > CREATE TABLE person (social_security CHAR(9), full_name TEXT);
> >
> > CREATE VIEW pers_view AS select social_security AS primkey,
> > social_security,
> > full_name);
> >
> > and know that you can always find the "primkey" field in the view
> as one
> > to use in where clauses for updates?
This is more-or-less a correct approach. As it does not address the
issue of different data types, let me tell you what I did:
Each significant data table contains one column, the first column,
called "usq", for "universal sequence". This usq field may or may not
be the primary key for the table, but does have a unique index. The usq
is populated by a single sequence "universal_sq" which is shared between
tables, thus allowing all tables usq uniqueness between them.
This strategy has allowed me to write a number of functions which are
table-agnostic, needing only the usq to do their job (such as a function
that creates modification hisotry).
-Josh Berkus
______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology [EMAIL PROTECTED]
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
