OK, if i did some thing to parse out the "default" from that, it
wouldnt be "SERIAL", it would just be a default object with the value
sitting inside of it (also what is ::regclass, does that have to be
filtered out ?). Also, when you go to INSERT a row, SA is giong to
explicitly run all the defaults as separate queries beforehand, as
opposed to letting the database run them automatically, since thats
what a "default" does. the explicit behavior is needed for at least
the primary key columns, as they are often needed right after INSERT
(and with rowids turned off, postgres/psycopg gives you no way of
getting at a recently inserted row otherwise). it could be modified
for non-primary-key columns to not run the default explicitly
beforehand....any opinions ?
Trying to guarantee that we know what data will be in the row before it is inserted sounds like a hard problem. The obvious difficulty is triggers, and in PG you have rules as well. So in at least those cases you will have to allow users to mark the table somehow as needing to be re-scanned after an insert/update. This could be generalized to column defaults as well. (If there's a lot of defaults, it could be more efficient to do one post-insert query than several pre-insert ones.)
--
Jonathan Ellis
http://spyced.blogspot.com
