Josh Berkus wrote: >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 > Hi Josh! Once you have your usq, how do you get more info about that row? How do you know which table it came from?
Thanks -- Dado Feigenblatt Wild Brain, Inc. Technical Director (415) 216-2053 [EMAIL PROTECTED] San Francisco, CA. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html