Обсуждение: Auto-increment and data importing: problem pointed out in PHP builder review?
Auto-increment and data importing: problem pointed out in PHP builder review?
От
"Randall Parker"
Дата:
Are the following comments correct? In particular, on his second complaint about the import and auto_increment: via what manner can one import a bunch of recordsand then not have the auto_increment next value be correct? I looked thru the faq (4.16.x doesn't mention this) and and some of the manuals (admin and user) didn't see anything relevant to this issuesecond issue. http://www.phpbuilder.com/columns/tim20000705.php3?page=1 Excerpt: At this point, I ran into another small issue with Postgres - its "serial" data type (the equivalent of MySQL's auto_increment) creates a "sequence" which does not get dropped when its parent table is dropped. So if you try to re-create the table, you'll get a name conflict for this sequence. A lot of new users would be confused by this, so Postgres loses a couple points for that. Also, MySQL is "smart" enough to increment its auto_increment value when you import data, whereas Postgres' sequence does not get reset when you import data, causing all new inserts to fail. Aside: does anyone know a good easy way with Apache to use some off-the-shelf plug-in to be able to dump a bunch of HTMLdoc in a directory (the PostgreSQL doc is what I have in mind) and index it and have a form where you can search it from?
"Randall Parker" <randall@nls.net> writes: > In particular, on his second complaint about the import and > auto_increment: via what manner can one import a bunch of records and > then not have the auto_increment next value be correct? I *think* what he's griping about is that a COPY IN doesn't automagically change the sequence counter to be >= last imported value for the serial column. Of course you can set the counter --- pg_dump scripts do so --- but it doesn't happen automatically. You could maybe force that to happen with a trigger, but IMHO the next work that ought to be done on SERIAL is to convert it into a "real" datatype. Then stuff like this could be made to happen in the datatype- specific I/O routines, which seems like a better answer ... regards, tom lane