Flutterby™! : postgres trivia

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

postgres trivia

2000-11-01 17:39:31+00 by Dan Lyke 4 comments

When altering a PostgreSQL trigger function, you have to delete and re-add all triggers which use the function. And you can't delete columns from tables. Oh well, we're back, PostgreSQL[Wiki] gets a reprieve for now, even though I'm only using the triggers to provide functionality that MySQL provides out of the box. Maybe this is a time for me to get involved in PostgreSQL[Wiki] development to try to fix some of the more boneheaded error conditions that it can get into.

comments in ascending chronological order (reverse):

#Comment made: 2002-02-21 05:30:29+00 by: ebradway

Are you trying to implement auto-incrementing fields in Postgres? Ironically, I just got finished implementing sequences in Sybase...

#Comment made: 2002-02-21 05:30:29+00 by: Dan Lyke

Actually, auto-incrementing fields are handled fairly well at version 7. There's a SERIAL type, which automagically defaults to a unique key and creates a sequence, which handles all the locking and unlocking via currval() and nextval() calls. You can either do a SELECT nextval('sequence_name') and insert the new number yourself (if, say, you needed the value back to insert children for the new record) or just do the insert and let the default take care of it for you. That bit actually seems like a better solution than the MySQL escape in the DBI driver system.

#Comment made: 2002-02-21 05:30:29+00 by: Dan Lyke

I suppose I should elaborate a bit: This was for triggers on "insert" and "updated" to handle entered and updated fields, my original insert trigger didn't put new values in the updated field. So I updated the function, and then had to delete and recreate the insert triggers.

#Comment made: 2002-02-21 05:30:30+00 by: ebradway

Are you writing self-modifying code again?