Relations between tables.
Being rather new to DBs in general, I wonder - is the relation constraint
present in PostgreSQL? Is this the same as relations I've seen under other
databases ? MS Access has to be a poor example but I've seen tables
relationed between themselves.
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?
christian
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
Import Notes
Resolved by subject fallback
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.
Show quoted text
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
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
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
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
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
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. __