Hey, Dado,
> 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?
Well, if you have to go at it from that angle (hey, I have this USQ,
where did it come from) then you're in trouble. However, I never use it
that way. Let me giv
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 dea
No, many of the tables have primary keys already, serial, single key or several keys.
I don't want to 'serialize' every table, because it does not make sense.
Oid's however are very usefull as I can use them as a primary key on any table.
Regards,
Aasmund.
On Fri, 19 Oct 2001 15:38:16 -0700,
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 probl
On Mon, 22 Oct 2001, Josh Berkus wrote:
> 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 "uni
That is what i did...
Regards,
Aasmund
On Sat, 20 Oct 2001 23:34:44 -0400 (EDT), Joel Burton <[EMAIL PROTECTED]> wrote:
> On Sun, 21 Oct 2001, Aasmund Midttun Godal wrote:
>
>
>
> Aasmund --
>
> If your problem is that you want to update VIEWs and aren't sure what the
> PK for the view is,
I apologize for not expressing myself clearly, and for replying without really giving
any new information. In hindsight I understand perfectly well, why you did not want to
continue communication, but I hope that you or someone else, will give me a second
chance on the issue.
Let me try to exp
Aasmund,
> I don't use them in indexes foreign keys etc., however they are very
> usefull when your application tries to edit/update individual rows,
> as the oid is like a universal primary key.
You'd still be better off defining your own SERIAL columns and/or
primary keys and using those. Som
On Fri, 19 Oct 2001 08:07:50 -0700, "Josh Berkus" <[EMAIL PROTECTED]> wrote:
> Aasmund,
>
>
> I believe the *official* reccommendation now is that you leave the OIDs
> to the system, and create your own SERIAL values for row identification.
> There are *lots* of problems with using OIDs as an in
Aasmund,
> The oid column will always be blank. The oid column can never be used
> for anything usefull.
I believe the *official* reccommendation now is that you leave the OIDs
to the system, and create your own SERIAL values for row identification.
There are *lots* of problems with using OIDs a
CREATE VIEW testview AS SELECT test.oid, tull FROM test;
ERROR: Attribute 'oid' has a name conflict
Name matches an existing system attribute
I think this should be allowed, because if you do:
CREATE VIEW testview AS SELECT tull FROM test;
SELECT oid, tull FROM testview;
The oid column
11 matches
Mail list logo
