Re: [SQL] need some help with a delete statement
On Wed, 2 Jul 2003, Matthew Hixson wrote: > Thanks for all your help, Scott. A friend of mine whipped out this > script which runs a lot faster than trying to use the original query I > posted. >-M@ > > begin; > create temporary table cart_temp as select distinct a.cart_id, > a.cart_cookie from v_carts a, v_cart_contents b where a.cart_id = > b.cart_id; > delete from v_carts; > insert into v_carts (cart_id, cart_cookie) select cart_id, cart_cookie > from cart_temp order by cart_id; > drop table cart_temp; > commit; > vacuum analyze verbose v_carts; > reindex table v_carts; Good ole batch processing. :-) Glad you got it working. ---(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] SEQUENCE and PRIMARY KEY
> >A trigger (maybe a rule) is the way to go about this. > > > >The alternative is to teach the bad clients to use DEFAULT rather than > >NULL when they expect the GENERATOR to create the value for them. > > > Hmm, Rod, there really seems a demand for the GENERATOR feature :-) > Do you see any performance problems with a trigger instead of a default? > I cant imagine that its so much of a difference (ok, depending on the > trigger, a > lookup in the catalog is needed, but still it should be fast enough, right?) A trigger written in C will have similar speeds as processing the default. Plpgsql isn't that slow, but it is slower -- probably not noticeably for this operation. signature.asc Description: This is a digitally signed message part
Re: [SQL] Inquiry From Form [pgsql]
On Wed, Jul 02, 2003 at 16:26:09 -0300, Chris Schneider <[EMAIL PROTECTED]> wrote: > I know this is basic, but couldn\'t find and in a hurry to know the answer. When > interfacing with PostgreSQL through PSQL, it appears that DML statements are > auto-commited, that is, a change I make in one session is seen from another without > the original session issueing a COMMIT. Is this a result of PSQL interface and if > so, can it be turned off. Is PostgreSQL transactional in the sense that I can issue > several DMLs and then ROLLBACK. If so, how. Thanks and sorry for the newbie > question. Autocommit is the default mode for psql. Use "begin;" to start a transaction. And use "end;" to end a transaction. Note that unlike in sqlplus with Oracle, any errors while in the transaction will abort it and you have to start over. All DML and most DDL statements are rollbackable by 7.3. I believe in 7.4 all DDL statements will be rollbackable. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] Inquiry From Form [pgsql]
On Thu, 3 Jul 2003, Bruno Wolff III wrote: > On Wed, Jul 02, 2003 at 16:26:09 -0300, > Chris Schneider <[EMAIL PROTECTED]> wrote: > > I know this is basic, but couldn\'t find and in a hurry to know the answer. When > > interfacing with PostgreSQL through PSQL, it appears that DML statements are > > auto-commited, that is, a change I make in one session is seen from another > > without the original session issueing a COMMIT. Is this a result of PSQL > > interface and if so, can it be turned off. Is PostgreSQL transactional in the > > sense that I can issue several DMLs and then ROLLBACK. If so, how. Thanks and > > sorry for the newbie question. > > Autocommit is the default mode for psql. Use "begin;" to start a transaction. > And use "end;" to end a transaction. Note that unlike in sqlplus with Oracle, > any errors while in the transaction will abort it and you have to start > over. > > All DML and most DDL statements are rollbackable by 7.3. I believe in 7.4 > all DDL statements will be rollbackable. Except drop database. That's one that'll probably never be rollbackable ;^) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
