Re: [GENERAL] pgaccess removed from 6.5.2?
Palle Girgensohn writes: Bruce Momjian wrote: The release notes talk about pgaccess beeing updated, but it is removed from the tarball? Only docs and demos are left; Makefile and tcl code is gone. How come? /Palle Not sure how that happened. I see it here. Well, it's not in the tarball. Here's an ls -l src/bin/pgaccess total 7 drwxr-xr-x 7 girgen wheel 512 Sep 16 02:22 ./ drwxr-xr-x 21 girgen wheel 512 Sep 16 02:22 ../ drwxr-xr-x 2 girgen wheel 512 Sep 16 02:22 demo/ drwxr-xr-x 3 girgen wheel 512 Sep 16 02:22 doc/ drwxr-xr-x 2 girgen wheel 512 Sep 16 02:22 images/ drwxr-xr-x 4 girgen wheel 512 Sep 16 02:22 lib/ drwxr-xr-x 3 girgen wheel 512 Sep 16 02:22 win32/ In 6.5.1, there was a Makefile and pgaccess.tcl in there, but not anymore. The Makefile in src/bin has references to the now non-existing Makefile. Same with me, I used the patch. ls -l src/bin/pgaccess drwxr-xr-x 2 uucp wheel1024 Jul 20 14:15 CVS/ -rw-r--r-- 1 uucp wheel 207 Nov 6 1998 a_right.gif drwxr-xr-x 2 root root 1024 Sep 22 10:55 demo/ drwxr-xr-x 3 root root 1024 Sep 22 10:55 doc/ drwxr-xr-x 4 root root 1024 Sep 22 10:55 lib/ -rw-r--r-- 1 uucp wheel 48128 Dec 12 1998 libpgtcl.dll -rw-r--r-- 1 uucp wheel 78336 Dec 12 1998 libpq.dll Dirk
Re: [GENERAL] when are indexes used?
hi, I just wait afew days to see whether some one ( with more info about this issue in pg ) reply. but ... so here is my word : From: InfraRED [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [GENERAL] when are indexes used? Date: Sun, 19 Sep 1999 17:29:57 +0200 (CEST) I noticed that indexes are not used sometimes when they could speed up queries: explain select * from auth where uid=30; Index Scan using auth_uid_key on auth (cost=2.05 rows=1 width=40) explain select * from auth where uid30; Seq Scan on auth (cost=2.06 rows=11 width=40) Testing on my machine it works fine. I mean this query uses the index file on my database. explain select * from auth order by uid; Sort (cost=2.06 rows=32 width=40) - Seq Scan on auth (cost=2.06 rows=32 width=40) are there any ways to speed up queries like these? the exact usage alg. of indexes is documented somewhere? when is this going to be fixed? It seems that in pg one may only use row field name at the where clause part of the query. ie : select * from auth where uid= 30 ; but if you want to use the index file,don't use it like this : select * from auth where uid= ( 28 + 2 ) ; also you may not use any function on the clause. ie : select * from auth where sqrt(uid)= 30 ; So you have to make the where clause statement very simple with no complexity. Though, due to my old knowledge about oracle, some databases supports these features a little stronger. I will also be glad to hear about more docs about indexing on pg. regards omid. __ Get Your Private, Free Email at http://www.hotmail.com
[GENERAL] Binary data?
Hi, can Postgres store binary data in TEXT fields? Or is there a solution except large objects? Dirk
[GENERAL] Re: [INTERFACES] Q: Mac: Openlink-Linux: Openlink-PostgreSQL
At 09:12 +0200 on 22/09/1999, Jelle Ruttenberg wrote: - password-file: PGDATA/pg_pwd - users in the password-file: added with CREATE USER - the passwords aren't encrypted - connecting the database with 'psql databasename -u' works - OpenLink uses the generic database-agent for PostgreSQL (95?) to connect to the database I am a bit on shaky ground here, but I think the frontend-backend protocol changed sometime between version 6.2 and 6.3. The specific change was in fact related to password authentication. (Gurus, correct me if I'm mistaken in this). The bottom line of all this is that if you want to use passwords, you have to have a frontend-backend agent/driver/module which is compatible with the new protocol. If you mentioned Postgre 95, it's probably an old, old agent. Herouth -- Herouth Maoz, Internet developer. Open University of Israel - Telem project http://telem.openu.ac.il/~herutma
Re: [SQL] [GENERAL] UPDATE feature or bug?
On Sep 22. 1999 at 11:13, Tom Lane wrote about Re: [SQL] [GENERAL] UPDATE feature Stuart Rison [EMAIL PROTECTED] writes: Now I've sussed this out as the update must be dealing with rows where b=4 first, trying to UPDATE them to b=3 and failing because these are already 'occupied'. Is this a bug? is this a feature? is there a way of telling the UPDATE what order to UPDATE in? It's a bug, but I doubt it's likely to get fixed any time soon, since unique indexes would get a LOT slower if they did this "right". As you say, the update must be hitting some of the b=4 rows first. At that point, the system has no idea that the existing b=3 rows are going to be invalidated in the same transaction, so its uniqueness check fails. To do this right, the uniqueness check would have to be applied at the end of the transaction, which would mean remembering every tuple that's been inserted/updated in the current transaction and going back to check its uniqueness. There is a running discussion on the hackers list about implementing referential integrity constraints, which have this same problem that you can't really apply (some kinds of) checks until you see the entire transaction results. It'll get done but it's not simple. I'm not sure whether anyone is thinking of applying that mechanism to unique- index checks... Well, my silly mind (not being very into the actual implementation of PostgreSQL) suggest, not a solution, but a temporary fix that you do as you normally do as long as there's no conflicts (i.e. do the check before each tuple), but when you reach a conflict, you simply remember the conflicting tuple until the end of the transaction, and then recheck for conflicts when the transaction has ended, but only on the remembered (and thus previously conflicting) tuples. If, at that time, the conflicts has been removed, the transaction is okay, otherwise it generates an error (and does a rollback). This has the implication that the complete transaction has to be able to be rolled back anyways (previously "good" tuples should not be altered as the complete transaction is not okay), so perhaps this is not a good idea after all. But on the other hand, your description (hitting some og the b=4 rows first) suggests that checks are done before altering each tuple (on that specific tuple), and not on the entire transaction before commiting any alterations, meaning that if anything goes wrong, the previous altered tuples will have to be rolled back, and thus it seems that there is already a knowledge of which tuples was altered (and how). I hope I made myself clear, and most likely my input is silly, but as stated above I don't know a lot about the implementation of PostgreSQL. Yours faithfully. Finn Kettner.
Re: [GENERAL] data type serial
So how do you store something in data type serial? I've created the column but everytime I attempt to do an update I get back the error message that I can't store a duplicate key. table_col_seq.last_value = 1 increment = 1 maxvalue = 2billion something I've tried storing 1,2,some other number in "serial" in the main table to no avail. What is the magic to get this to work. There appears to be no documentation anywhere on the necessary SQL commands to cycle the generator. I've tried the method used for Oracle SQL but that does not work. I'm a bit of a newbie at this. Michael [EMAIL PROTECTED] You cant insert into a serial as far as I know. The serial is simply incrimented automatically whenever a new INSERT is done on the table. Hmmm that's a real problem when adding it to an existing table. The values I get back on a select indicate all blanks. I've got several hundred records in the table at the moment. There must be a way to update the darn things. Michael [EMAIL PROTECTED]
Re: [GENERAL] data type serial
Michael wrote: So how do you store something in data type serial? I've created the column but everytime I attempt to do an update I get back the error message that I can't store a duplicate key. table_col_seq.last_value = 1 increment = 1 maxvalue = 2billion something I've tried storing 1,2,some other number in "serial" in the main table to no avail. What is the magic to get this to work. There appears to be no documentation anywhere on the necessary SQL commands to cycle the generator. I've tried the method used for Oracle SQL but that does not work. I'm a bit of a newbie at this. Michael [EMAIL PROTECTED] You cant insert into a serial as far as I know. The serial is simply incrimented automatically whenever a new INSERT is done on the table. Hmmm that's a real problem when adding it to an existing table. ? you can create another serial, starting @ max(serial attr)+1 The values I get back on a select indicate all blanks. I've got several hundred records in the table at the moment. There must be a way to update the darn things. it should not, how do you make that select 7 what's the table definition? Michael [EMAIL PROTECTED] -- CIMPOESU Teodor, Web Programmer (h) @ DIGICOM S.A. Bucharest, Romania @ Internet, site development @ [EMAIL PROTECTED], +(401)-330.47.28 official home page ~ http://www.digiro.net/ Internet web page ~ http://internet.digiro.net/
Re: [GENERAL] data type serial
If you have this table:
create table testing (
id serial,
datatext,
md int
);
You would use:
insert into testing (data, md) values ('my_data', 12);
insert into testing (data, md) values ('more data', 15);
The key part is that you don't specify the serial field in your insert command.
Anyway, hope this helps.
At 09:45 PM 9/22/99, Michael wrote:
So how do you store something in data type serial?
I've created the column but everytime I attempt to do an update I get
back the error message that I can't store a duplicate key.
table_col_seq.last_value = 1
increment = 1
maxvalue = 2billion something
I've tried storing 1,2,some other number in "serial" in the main
table to no avail. What is the magic to get this to work. There
appears to be no documentation anywhere on the necessary SQL commands
to cycle the generator. I've tried the method used for Oracle SQL but
that does not work. I'm a bit of a newbie at this.
Michael
[EMAIL PROTECTED]
You cant insert into a serial as far as I know.
The serial is simply incrimented automatically whenever a new INSERT
is done on the table.
Hmmm that's a real problem when adding it to an existing table.
The values I get back on a select indicate all blanks. I've got
several hundred records in the table at the moment. There must be a
way to update the darn things.
Michael
[EMAIL PROTECTED]
Re: [GENERAL] data type serial
So how do you store something in data type serial? I've created the column but everytime I attempt to do an update I get back the error message that I can't store a duplicate key. table_col_seq.last_value = 1 increment = 1 maxvalue = 2billion something I've tried storing 1,2,some other number in "serial" in the main table to no avail. What is the magic to get this to work. There appears to be no documentation anywhere on the necessary SQL commands to cycle the generator. I've tried the method used for Oracle SQL but that does not work. I'm a bit of a newbie at this. Michael [EMAIL PROTECTED] You cant insert into a serial as far as I know. The serial is simply incrimented automatically whenever a new INSERT is done on the table. Hmmm that's a real problem when adding it to an existing table. The values I get back on a select indicate all blanks. I've got several hundred records in the table at the moment. There must be a way to update the darn things. Michael [EMAIL PROTECTED] You could create a new table with the same attributes as the old, but with the serial in it, then insert into newone select from oldone... Then drop the old one and rename the new one That SHOULD do it (Ive not tried, I think it will tho) ~Michael
