Re: [SQL] ENUM like data type
On 6/28/05, Martín Marqués wrote: > El Mar 28 Jun 2005 13:58, PFC escribió: > > Personnally I use one table which has columns (domain, name) and which > > stores all enum values for all different enums. > > I have then CHECK( is_in_domain( column, 'domain_name' )) which is a > > simple function which checks existence of the value in this domain (SELECT > > 1 FROM domains WHERE domain=$2 AND name=$1 LIMIT 1) for instance. > > You can also use integers. > > I personally think that the ENUM data type is for databases that are not well > designed. So, if you see the need for ENUM, that means you need to re-think > your data design. I seem to remember some discussion here, half a year ago perhaps which was about something similar (while not exactly). I mean it I think it someone said that DB2 (I am not sure about that one) has a feature that enables it to normalize the table behind the scenes. As I remember it, it works somewhere along the lines of: -- you create table CREATE TABLE foo ( when timestamptz, useragent some_data_type_perhaps ); ...and RDBMS will create a lookup table for useragents for you, with serial key, etc, etc. And in our foo table useragent will be kept as a reference to that lookup table. When you do a select, lookup table will be consulted behind the scenes, etc, etc. All this is doable with RULEs and VIEWs (and triggers for populating). Well, what MRB had in mind was more like a special subcase of such approach (lookup table with "read-only" keys), but I think such a lookup table would be benefitial for many users, especially when dealing with large tables. Incidentally, does it qualify for todo? Or maybe its already there? Regards, Dawid ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [SQL] ORDER records based on parameters in IN clause
>> when I say >> select * from table where id IN (2003,1342,799, 1450) >> I would like the records to be ordered as 2003, 1342, 799, 1450. >Just say: >select * from table where id IN (2003,1342,799, 1450) ORDER BY id; >If that doesn't work, you will have to be more specific and send us the exact query. Order by id will not do what you want, but this should. Select * from table where id = 2003; Union all Select * from table where id = 1342; Union all Select * from table where id = 799; Union all Select * from table where id = 1450; ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] ORDER records based on parameters in IN clause
On 6/27/05, Riya Verghese <[EMAIL PROTECTED]> wrote: > I have a stmt where the outer-query is limited by the results of the inner > query. I would like the outer query to return records in the same order as > the values provided in the IN clause (returned form the inner query). > > The inner_query is returning id's ordered by count(id) , i.e by most common > occurrence. > > In essence, > > when I say > > select * from table where id IN (2003,1342,799, 1450) > > Currently postgres returns it in this order (1450,1342,799,2003) Simplest, though not niciest solution would be: SELECT * FROM table WHERE id IN (2003,1342,799,1450) ORDER BY id = 2003 DESC, id = 1342 DESC, id = 799 DESC, id = 1450 DESC; You could write a function which will return position of interger inside integer[] array and use it as order key. :-) Regards, Dawid ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [SQL] ORDER records based on parameters in IN clause
On Wed, Jun 29, 2005 at 07:19:22AM -0400, Russell Simpkins wrote: > > Order by id will not do what you want, but this should. > Select * from table where id = 2003; > Union all > Select * from table where id = 1342; > Union all > Select * from table where id = 799; > Union all > Select * from table where id = 1450; Note that the semicolons should be omitted everywhere except for at the end of the entire query. Also, although the implementation might happen to return rows in that order, the documentation states that it's not guaranteed to: http://www.postgresql.org/docs/8.0/static/queries-union.html "UNION effectively appends the result of query2 to the result of query1 (although there is no guarantee that this is the order in which the rows are actually returned)." As the documentation states elsewhere and as the SQL standard says, without ORDER BY rows are returned in an unspecified order. The above query works by accident, not by design, so although it might work today there's no guarantee that it'll work tomorrow. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] ORDER records based on parameters in IN clause
Riya Verghese wrote: select * from table where id IN (2003,1342,799, 1450) I would like the records to be ordered as 2003, 1342, 799, 1450. The outer query has no knowledge of the count(id) that the inner_query is ordering by. I think this is the real problem: outer query must know count(id) to order by count(id). You can use it in the outer with something like this: SELECT table.* FROM table JOIN (SELECT id, count(id) AS count FROM... your subquery) AS x ORDER BY x.count Bye. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [SQL] ORDER records based on parameters in IN clause
SELECT table.* FROM table JOIN (SELECT id, count(id) AS count FROM... your subquery) AS x ORDER BY x.count Bye. Sorry: I forgot join condition: SELECT table.* FROM table JOIN (SELECT id, count(id) AS count FROM... your subquery) AS x ON (table.id = x.id) ORDER BY x.count ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] ENUM like data type
| |I personally think that the ENUM data type is for databases |that are not well |designed. So, if you see the need for ENUM, that means you |need to re-think |your data design. | I disagree. In several relations (views of the world) one needs to have a hand full of well defined values while integers or bools are not appropriate and strings are too free form. For example male female or true and false. Whilst the second has a well known type, other things like a telephone number type don't have such type. So a new one should be created instead of (varchar/ xy between 4 and 8). One might argue that new 1:n relations with integrity shall be established but this is in my eyes overkill for a constant number of values. Also think of schema export without data. These values are part of the schema data but not the schema itself which in this sense is wrong |-- |select 'mmarques' || '@' || 'unl.edu.ar' AS email; |- |Martín Marqués | Programador, DBA |Centro de Telemática | Administrador | Universidad Nacional |del Litoral |- | |---(end of |broadcast)--- |TIP 4: Don't 'kill -9' the postmaster | ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[SQL] Insert rule and default values for PK
Hi,
I've a prolem inserting records in a view using different ways.
I want to insert either way, with PK given and without PK which should then
be taken by its DEFAULT stanza:
insert into a_and_b(a) values (537)# id not given, self assigned
insert into a_and_b(x) values (true)# id not given, self assigned
insert into a_and_b(x,id) values (true,55) # id given, take that
For this example I created two tables. Note the Serial at tbla:
CREATE TABLE tbla
(
id int4 NOT NULL,
a int4,
b varchar(12), CONSTRAINT tbla_pk PRIMARY KEY (id)
)
CREATE TABLE tblb
(
id int4 NOT NULL,
x bool, y timestamp,
CONSTRAINT tblb_pk PRIMARY KEY (id),
CONSTRAINT tblb_fk FOREIGN KEY (id) REFERENCES tbla (id) ON UPDATE CASCADE
ON DELETE CASCADE
)
My view is defined as to concatinate this 1:1 relation:
CREATE OR REPLACE VIEW a_and_b AS
SELECT tbla.id, tbla.a, tbla.b, tblb.x, tblb.y
FROM tbla NATURAL LEFT OUTER JOIN tblb;
In the first run I tried this insert rule. But it turned out that I can't
insert rows, if I omit id
CREATE OR REPLACE RULE a_b_insert AS
ON INSERT TO a_and_b DO INSTEAD (
INSERT INTO tbla (id, a, b) VALUES (new.id, new.a, new.b);
INSERT INTO tblb (id, x, y) VALUES (new.id, new.x, new.y););
So I had a try with that rule which already does what was intended. I can
now choose of wheter I want to supply id of if not.
However I get disturbed by the 'nextval' and 'curval'-functions. This is
redundant with the tables definition. I don't like that.
The other way round, leave all id out, helps for tbla (since a default is
defined) but leaves tblb alone:
CREATE OR REPLACE RULE a_b_insert AS
ON INSERT TO a_and_b DO INSTEAD ( INSERT INTO tbla (id, a, b)
VALUES (coalesce(new.id,nextval('public.tbla_id_seq'::text)), new.a,
new.b);
INSERT INTO tblb (id, x, y)
VALUES (coalesce(new.id,currval('public.tbla_id_seq'::text)), new.x,
new.y);
);
What would you do? What is the postgres way of solving this problem.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [SQL] ENUM like data type
El Mié 29 Jun 2005 09:40, KÖPFERL Robert escribió: > > | > |I personally think that the ENUM data type is for databases > |that are not well > |designed. So, if you see the need for ENUM, that means you > |need to re-think > |your data design. > | > > I disagree. In several relations (views of the world) one needs to have a > hand full of well defined values while > integers or bools are not appropriate and strings are too free form. > For example male female or true and false. Whilst the second has a well > known type, other things like a telephone number type don't have such type. > So a new one should be created instead of (varchar/ xy between 4 and 8). One > might argue that new 1:n relations with integrity shall be established but > this is in my eyes overkill for a constant number of values. > Also think of schema export without data. These values are part of the > schema data but not the schema itself which in this sense is wrong Please, most of this can be done with CHECK(...). -- select 'mmarques' || '@' || 'unl.edu.ar' AS email; - Martín Marqués | Programador, DBA Centro de Telemática| Administrador Universidad Nacional del Litoral - ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [SQL] cross-table reference
Please keep replies copied to the list unless you have a specific reason not to. This lets more people potentially help you and lets others learn from the discussion. On Wed, Jun 29, 2005 at 14:09:16 +0530, Mukesh Ghatiya <[EMAIL PROTECTED]> wrote: > Hi Bruno, > > Thanks for the response. Ok, let me clarify my problem further. > My actual problem is to convert a simplistic query of form "SELECT > table1.a.b.x table1.a.c.x from table1;" to its working SQL equivalent. > The input query can be further complex in terms of depth of the columns, > number of columns, and such multi-level-columns can be present in > 'where' clause as well. > > Now, I hope you realize it will be a quite tricky job to write a generic > algorithm to convert such a query to its sql equivalent. So I was just > wondering if the output can be simplified, that will make the algo less > tricky. I don't think having simpler output is needed for this. The custom query generator needs to understand what you are telling it. Once it does it should be able to produce the required output. > Also, I was just wondering why doesn't DB support such queries? It looks > so intuitive (and small) to write such queries. > Ideally DB should be able to do this, because it knows that 'a' is an > attribute in 'table1' which is a foreign key to 'table2', and so on. Talk to the SQL Standards committee. The syntax you are suggesting is going to conflict with existing meaning. > Please let me know if I didn't make myself clear. > > Thanks, > Mukesh > > -Original Message- > From: Bruno Wolff III [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 28, 2005 6:18 PM > To: Mukesh Ghatiya > Cc: [email protected] > Subject: Re: cross-table reference > > On Wed, Jun 22, 2005 at 14:56:08 +0530, > Mukesh Ghatiya <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I need to perform a query similar to > > > > SELECT table1.a.b.x table1.a.c.x from table1; > > > > > > In this case "a" is an attribute in 'table1' and is a foreign key to > > other table2 which has 'b', and 'c' as attributes, which again are > > foreign keys to table3. > > > > > > Is there any simple way of doing this other than using the complicated > > > nested joins which would include aliases also. > > > > SELECT table31.x table32.x > > FROM table1, table3 AS table31, table3 AS table32 WHERE table1.a = > > table2.id > > AND table2.b = table31.id > > AND table2.c = table32.id > > This isn't really that complicated. (Though note you left table2 out of > the from item list.) You might be able to reasonable performance and > simplify the select statement by defining two functions to select from > table2 and table3. > If this were written in language SQL the query might even end up with > essentially the same plan. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [SQL] ENUM like data type
On Wed, 2005-06-29 at 10:21 -0300, Martín Marqués wrote: > El Mié 29 Jun 2005 09:40, KÖPFERL Robert escribió: > > > > | > > |I personally think that the ENUM data type is for databases > > |that are not well > > |designed. So, if you see the need for ENUM, that means you > > |need to re-think > > |your data design. > > | > > > > I disagree. In several relations (views of the world) one needs to have a > > hand full of well defined values while > > integers or bools are not appropriate and strings are too free form. > > For example male female or true and false. Whilst the second has a well > > known type, other things like a telephone number type don't have such type. > > So a new one should be created instead of (varchar/ xy between 4 and 8). One > > might argue that new 1:n relations with integrity shall be established but > > this is in my eyes overkill for a constant number of values. > > Also think of schema export without data. These values are part of the > > schema data but not the schema itself which in this sense is wrong > > Please, most of this can be done with CHECK(...). Indeed. A CHECK constraint on a DOMAIN is an ENUM plus some. -- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [SQL] ORDER records based on parameters in IN clause
fair enough. but a simple order by id would never work. From: Michael Fuhr <[EMAIL PROTECTED]> To: Russell Simpkins <[EMAIL PROTECTED]> CC: [email protected] Subject: Re: [SQL] ORDER records based on parameters in IN clause Date: Wed, 29 Jun 2005 05:57:23 -0600 On Wed, Jun 29, 2005 at 07:19:22AM -0400, Russell Simpkins wrote: > > Order by id will not do what you want, but this should. > Select * from table where id = 2003; > Union all > Select * from table where id = 1342; > Union all > Select * from table where id = 799; > Union all > Select * from table where id = 1450; Note that the semicolons should be omitted everywhere except for at the end of the entire query. Also, although the implementation might happen to return rows in that order, the documentation states that it's not guaranteed to: http://www.postgresql.org/docs/8.0/static/queries-union.html "UNION effectively appends the result of query2 to the result of query1 (although there is no guarantee that this is the order in which the rows are actually returned)." As the documentation states elsewhere and as the SQL standard says, without ORDER BY rows are returned in an unspecified order. The above query works by accident, not by design, so although it might work today there's no guarantee that it'll work tomorrow. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] ORDER records based on parameters in IN clause
On Wed, Jun 29, 2005 at 10:22:07AM -0400, Russell Simpkins wrote: > > fair enough. but a simple order by id would never work. I didn't mean to imply that it would -- I meant only that ORDER BY is necessary to guarantee a particular row order. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [SQL] ORDER records based on parameters in IN clause
On Wed, 2005-06-29 at 09:22, Russell Simpkins wrote: > fair enough. but a simple order by id would never work. > Try this: select *, case when id=2003 then 1 when id=1342 then 2 when id=799 then 3 when id=1450 then 4 end as ob from tablename where id in (2003,1342,799,1450) order by ob; ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [SQL] ENUM like data type
Rod Taylor wrote: > Indeed. A CHECK constraint on a DOMAIN is an ENUM plus some. Not really. A domain doesn't create a new type. If you base your enum domains on the text type, as would usually be the case, then nothing stops you from using, say, text concatenation operators and the like. I suppose in practice this won't matter too much, but it can't be called a clean design. What you'd really need is a way to create a distinct type. SQL has a feature for that, but PostgreSQL hasn't implemented it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] ENUM like data type
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Rod Taylor wrote: >> Indeed. A CHECK constraint on a DOMAIN is an ENUM plus some. > Not really. A domain doesn't create a new type. If you base your enum > domains on the text type, as would usually be the case, then nothing > stops you from using, say, text concatenation operators and the like. > I suppose in practice this won't matter too much, but it can't be > called a clean design. What you'd really need is a way to create a > distinct type. SQL has a feature for that, but PostgreSQL hasn't > implemented it. It's not that hard to make your own type using the builtin textin and textout functions, and then add just the functions you wish to provide. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[SQL] Error saving image to PostgresSQL 8.x database
In PostgreSQL 7.1
Documentation Chapter 8.
JDBC Interface the example below is
used to store a image file into the database.
I am using J2SE
5.02 and Pervasive Postgres 8 Release 2 with
postgresql-8.0-310.jdbc3 driver.
Example 8-2. Using the JDBC Large Object
Interface
For example, suppose you have a table containing the file name of an image
and you have a large object containing that image: CREATE TABLE images (imgname text, imgoid oid);
To insert an image, you would use: File file = new File("myimage.gif");
FileInputStream fis = new FileInputStream(file);
PreparedStatement ps = conn.prepareStatement("INSERT INTO images VALUES (?, ?)"); (1)
ps.setString(1, file.getName());
ps.setBinaryStream(2, fis, file.length());
ps.executeUpdate();
ps.close();
fis.close(); I have used this example code to create my own method to save an image file. The code is listed below:** * This method saves the current record if it has been modified. * * @return Integer. */ private void saveImageRec() { java.sql.Date sqlDate; java.sql.Time sqlTime; java.sql.Timestamp sqlTimestamp; java.util.Date now; long nowLong; int returnVal; PreparedStatement ps = null; File file = null; FileInputStream fis = null; int vehinfoid = 0; //Get the cuurent date, time and timestamp now = new java.util.Date(); nowLong = now.getTime(); sqlDate = new java.sql.Date(nowLong); sqlTime = new java.sql.Time(nowLong); sqlTimestamp = new java.sql.Timestamp(nowLong); try { file = new File(photoFilePath); fis = new FileInputStream(file); } catch (NullPointerException e) { System.out.println(e.getMessage()); } catch (FileNotFoundException e) { System.out.println(e.getMessage()); } try { pgconn.connection.setAutoCommit(false); vehinfoid = (Integer)vehicleinfoTable.getValue(0, "vehinfoid"); if (newrec) { ps = pgconn.connection.prepareStatement("INSERT INTO tbl_images VALUES (?, ?, ?, ?, ?, ?, ?, ?)"); ps.setInt(1, vehinfoid); //vehinfoid ps.setString(2, file.getName()); //Image file name ps.setBinaryStream(3, fis, (int) file.length()); //image file ps.setDate(4, sqlDate); //changeddate ps.setTime(5, sqlTime); //changedtime ps.setString(6, "Fred Cunningham"); //changedby ps.setTimestamp(7, sqlTimestamp); //creationdatetime ps.setString(8, "Fred Cunningham"); //createdby } else { ps = pgconn.connection.prepareStatement("UPDATE tbl_images SET imagename = ?, imageoid = ?, changeddate = ?, changedtime = ?, changedby = ? WHERE vehinfoid = ?"); ps.setString(1, file.getName()); //Image file name ps.setBinaryStream(2, fis, (int) file.length()); //image file ps.setDate(3, sqlDate); //changeddate ps.setTime(4, sqlTime); //changedtime ps.setString(5, "Fred Cunningham"); //changedby ps.setInt(6, vehinfoid); //dispatchid } returnVal = ps.executeUpdate(); ps.close(); fis.close(); } catch (SQLException e) { System.out.println(e.getMessage()); } catch (IOException e) { System.out.println(e.getMessage()); } } - table ---CREATE TABLE tbl_images( imageid int4 NOT NULL DEFAULT nextval('public."tbl_images_imagid_seq"'::text), vehinfoid int4 NOT NULL, imagename text, imageoid oid, changeddate date NOT NULL, changedtime time NOT NULL, changedby varchar(25) NOT NULL, creationdatetime timestamp NOT NULL, createdby varchar(25) NOT NULL, CONSTRAINT tbl_images_pk PRIMARY KEY (imageid)) WITHOUT OIDS;ALTER TABLE tbl_images OWNER TO postgres;GRANT ALL ON TABLE tbl_images TO postgres;GRANT ALL ON TABLE tbl_images TO GROUP tsam;when I execute the code I get the error listed below: ERROR: column "imageoid" is of type oid but _expression_ is of type bytea Can anyone tell what I doing wrong. Thanks Fred Cunningham
[SQL] Foreign key pg_dump issue and serial column type
Hi, As a relative newbie to postgres, I've run into to weirdisms that I don't quite know how to handle: 1. I have a many-to-many table 'people_roles' containing fields 'person_code' and 'role_code'. It links tables 'people' and 'roles'. There are foreign key constraints: ALTER TABLE PEOPLE_ROLES add CONSTRAINT PRO_PEE_FK FOREIGN KEY(PERSON_CODE) REFERENCES PEOPLE(PERSON_CODE) ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE; ALTER TABLE PEOPLE_ROLES add CONSTRAINT PRO_ROE_FK FOREIGN KEY(ROLE_CODE) REFERENCES ROLES(ROLE_CODE) ON DELETE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE; However, when I pg_dump the database and import it on another server, the tables are exported alphabetically, so when the 'people_roles' table is created with its foreign keys, the table 'roles' does not exist yet. Thus, the foreign key creation fails. Is there a way around it? 2. I've just discovered the 'serial' column type and tried to do this: alter table people_roles alter column people_roles_code type serial; To my surprise, it fails: ERROR: type "serial" does not exist However, I can create new tables with the 'serial' type without a hitch. Is it a bug or a feature? I'm running postgres 8.0.3 on Fedora Core 4. Thanks, Simon -- Simon (Vsevolod ILyushchenko) [EMAIL PROTECTED] http://www.simonf.com Terrorism is a tactic and so to declare war on terrorism is equivalent to Roosevelt's declaring war on blitzkrieg. Zbigniew Brzezinski, U.S. national security advisor, 1977-81 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [SQL] Foreign key pg_dump issue and serial column type
"Vsevolod (Simon) Ilyushchenko" <[EMAIL PROTECTED]> writes: > However, when I pg_dump the database and import it on another server, > the tables are exported alphabetically, so when the 'people_roles' table > is created with its foreign keys, the table 'roles' does not exist yet. > Thus, the foreign key creation fails. Is there a way around it? Are you sure you are using 8.0 pg_dump? That's a longstanding deficiency in older versions, but 8.0 is not supposed to have a problem with it. If you're sure it's an up-to-date pg_dump, could you provide a complete test case (ie, a script to create a database that pg_dump has trouble with)? > 2. I've just discovered the 'serial' column type and tried to do this: > alter table people_roles alter column people_roles_code type serial; > To my surprise, it fails: > ERROR: type "serial" does not exist Serial isn't quite a true type, and so it doesn't work in every context that you might think. It'd probably make sense for "alter column type" to accept it, but for now what you gotta do is create a sequence and set the column default manually. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [SQL] Error saving image to PostgresSQL 8.x database
Fred, > In PostgreSQL 7.1 Documentation Chapter 8. JDBC Interface the example > below is used to store a image file into the database. I am using J2SE > 5.02 and Pervasive Postgres 8 Release 2 with postgresql-8.0-310.jdbc3 > driver. Example 8-2. Using the JDBC Large Object Interface Why are you reading the 7.1 docs and using 8.0? How about reading the 8.0 docs? -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
