Horton
Menu

Thread

  1. RE: [GENERAL] Relations between tables.

    Jackson, DeJuan <djackson@cpsgroup.com> — 1999-05-20T18:01:25Z

    > Being rather new to DBs in general, I wonder - is the relation constraint
> present in PostgreSQL? 
Not in and of itself.   The FOREIGN KEY CONSTRAINT syntax is parsed but not
implemented.
> Is this the same as relations I've seen under other databases ?
Should be.
> MS Access has to be a poor example but I've seen tables relationed between
> themselves.
MS Access is a very poor example of most things SQL92.

> Using a relation constraint, are tables tied together automatically, thus
> removing the need to use a 'WHERE table1.index = table2.t1index' in select
> clauses retreiving data in table2 and table1?
Nope this doesn't even happen in MS Access.  If you build your query in
Access and look at the SQL (go to the View menu the select SQL) that's
generated you'll see that all Access is put that part of the WHERE clause in
for you.  Most other databases aren't that presumptuous.

> christian
	-DEJ

  2. RE: [GENERAL] Relations between tables.

    Rudy Gireyev <rgireyev@cnmnetwork.com> — 1999-05-20T18:46:15Z

    
On 20 May 99, at 13:01, Jackson, DeJuan wrote:

> > Being rather new to DBs in general, I wonder - is the relation

<snip> 

> > Using a relation constraint, are tables tied together automatically,
> > thus removing the need to use a 'WHERE table1.index = table2.t1index' in
> > select clauses retreiving data in table2 and table1?

You can essentially achive this by creating a view, and then
selecting against the view, rather than the individual tables within it.

> Nope this doesn't even happen in MS Access.  If you build your query in
> Access and look at the SQL (go to the View menu the select SQL) that's
> generated you'll see that all Access is put that part of the WHERE clause
> in for you.  Most other databases aren't that presumptuous.
> 
> > christian
>  -DEJ
> 
> 
>

  3. RE: [GENERAL] Relations between tables.

    christian <crr@freemail.com.br> — 1999-05-21T21:05:43Z

    On Thu, 20 May 1999, Jackson, DeJuan wrote:

> Not in and of itself.   The FOREIGN KEY CONSTRAINT syntax is parsed but not
> implemented.

Are there plans for this _important feature_ :) being implemented?

> > MS Access has to be a poor example but I've seen tables relationed between
> > themselves.
> MS Access is a very poor example of most things SQL92.

Okay, okay, forget access. I knew I was going to draw flames on this
comparison.

> Nope this doesn't even happen in <omitted>.  If you build your query
> in <omitted> and look at the SQL (go to the View menu the select SQL)
> that's generated you'll see that all <omitted> is put that part of the
> WHERE clause in for you.  Most other databases aren't that
> presumptuous.

You're right. The constraint is simply a constraint - rows in this table
must have a key listed in the column/table referred to in the Primary Key.
Correct?

cr

  4. Re: [GENERAL] Relations between tables.

    Bruce Momjian <maillist@candle.pha.pa.us> — 1999-05-21T21:18:42Z

    > On Thu, 20 May 1999, Jackson, DeJuan wrote:
> 
> > Not in and of itself.   The FOREIGN KEY CONSTRAINT syntax is parsed but not
> > implemented.
> 
> Are there plans for this _important feature_ :) being implemented?

Jan says 6.6, perhaps.  Maybe he can comment.  This is our #1 missing
feature after 6.5 is released.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  5. Re: [GENERAL] Relations between tables.

    Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu> — 1999-05-21T21:40:56Z

    Bruce Momjian wrote:
> > On Thu, 20 May 1999, Jackson, DeJuan wrote:
> > 
> > > Not in and of itself.   The FOREIGN KEY CONSTRAINT syntax is parsed but not
> > > implemented.
> > 
> > Are there plans for this _important feature_ :) being implemented?
> 
> Jan says 6.6, perhaps.  Maybe he can comment.  This is our #1 missing
> feature after 6.5 is released.

And #2 is OUTER JOINS? please, oh please?

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005

  6. oid and index

    Jonathan davis <haj@idianet.net> — 1999-06-17T14:53:50Z

    hello

one question

what's the difference between oid and index ?

  7. Re: [GENERAL] oid and index

    Herouth Maoz <herouth@oumail.openu.ac.il> — 1999-06-20T10:49:16Z

    At 17:53 +0300 on 17/06/1999, Jonathan Davis wrote:


>
> one question
>
> what's the difference between oid and index ?

An oid is a unique number given automatically to every object in a
PostgreSQL database, such as a row or a large object.

An index is a method of accelerating access to the database when the query
is done on specific fields. If the fields are indexed, SELECT operations
using them will generally be faster, but INSERT and UPDATE may be slightly
slower.

There is really no connection between an oid and an index, except for the
fact that you can create an index on the oid attribute of a table, and thus
accelerate retrieval of rows by their oids.

Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma

  8. Re: [GENERAL] oid and index

    Dustin Sallings <dustin@spy.net> — 1999-06-20T17:30:17Z

    On Sun, 20 Jun 1999, Herouth Maoz wrote:

// An oid is a unique number given automatically to every object in a
// PostgreSQL database, such as a row or a large object.

	Are these not being done away with?  I remember there was
discussion about getting rid of this a while back.

--
Principal Member Technical Staff, beyond.com    The world is watching America,
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE 
L______________________________________________ and America is watching TV. __