Flutterby™! : postgres trivia 2000-11-01 17:39:31+00

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 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 development to try to fix some of the more boneheaded error conditions that it can get into.

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

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.

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.