将序列更新到PostgresQL中的下一个可用序列

Question

OK, I'm making user database in PostgresQL, which I have been using for a month or two, but am not very familiar with. Currently, each user that registers is auto-assigned a unique ID via a PostgresQL sequence. This has always been the practice and has always worked fine, HOWEVER... I have a request from the client to be able to manually enter users certain IDs. I'm not expecting more than 300 users, so I was reserving IDs 500-600 for manually-entered IDs. (If they register online, they get the auto-incremented number, most likely not over 300. If they need a manual ID, they are given a pre-determined ID between 500 and 600 only.) Yes, I am 99.9999% sure that there will not be more than 300 'auto-id' users.

I would really like to be able to give any manual ID I'd like and then if they register online and the ID is already taken, they get the next available ID. I realize this defeats the purpose of the sequence, however, I'm not sure what my other option is. I only have a certain number of IDs I can give out, so I'd rather not just 'max+1', if possible - I'd like to "fill in the gaps". I'm fairly sure the answer lies somewhere in updating the sequence when an ID is manually entered, but that sounds like a bad idea, not sure why.

If it's not a great idea, just say - "Hey, you're a moron. Who put you in charge of a database?" and we'll all go about our day. Thanks for your time.

Answer 1

I'd probably DROP the sequence completely and ALTER TABLE to remove the default from the column. Then, during INSERT , I'd write something like:

BEGIN;
LOCK TABLE users IN EXCLUSIVE MODE;
INSERT INTO users (user_id, blah, blah)
VALUES (
   coalesce(
       requested_id_or_null_if_none_supplied,
       (SELECT coalesce(max(user_id),0) FROM users)+1
   ),
   'blah',
   'blah'
);
COMMIT;

This has bad concurrency. Exactly one transaction can be inserting a user at any given moment. Given the volumes you're working with that should be perfectly fine so long as you keep your transactions short.

Consider adding a new field that's used as a public display identifier , separate to the database's internal primary key . Use this field for display for the customer's purposes. Let them put whatever they want in it, just declare it UNIQUE as part of a suitable unique key.

If you do that you can keep the underlying number assignment using a sequence the same, so you don't have to change how you refer to the users elsewhere in the DB. You don't have to change how any of the rest of the app refers to users internally. When displaying a user identifier, just look up the "user number" for display and use that. When the user enters a user number, look up the primary key of the matching row. The user number is only needed for input/output as an identifier for the end user, it doesn't get referenced in the rest of the database.

This is why database/app design wisdom stresses that you should generally not expose generated keys to the user . Eventually, if they can see them they'll inevitably want to be able to change them with "fun" results. Much easier to give them their own public identifier to play with. If they suddenly decide it should be alphanumeric, but only on Tuesdays with a full moon - that's OK, you can do that.

Once you've split the "display identifier" and "unique internal row key" into separate things, you're free to do whatever you want with the display identifier, including easily letting them change it.

Answer 2

You obviously got your lecture on how to use a sequence properly . You show some insight in the question and @Craig's answer covers the gaps comprehensively.

As to your question, I would go about it the other way round :
Reserve a pool of special numbers for special guests. Special numbers should be short.
Start your sequence at, say, 10000 (for your case). No need to be thrifty, sequence numbers are cheap and abundant.

CREATE TABLE usr (
  usr_id serial PRIMARY KEY
 ,usr text   -- UNIQUE??
);

-- Let sequence start at 10000
SELECT setval('usr_usr_id_seq', 10000, FALSE);

-- Init table with first user if you want to start at certain number
-- Else numbers start at the lowest manual entry.
INSERT INTO usr(usr_id, usr) VALUES (1, 'first_user');

Special INSERT (take first free number, if requested number not available):

WITH x AS (SELECT 4::int AS usr_id, 'special_guest' AS usr)
INSERT INTO usr(usr_id, usr)
SELECT CASE
         WHEN x.usr_id IS NULL THEN nextval('usr_usr_id_seq'::regclass)
         WHEN EXISTS (SELECT 1 FROM usr u WHERE u.usr_id = x.usr_id) THEN (
            SELECT u.usr_id + 1
            FROM   usr u
            WHERE  NOT EXISTS (SELECT 1 FROM usr u1
                               WHERE  u1.usr_id = u.usr_id + 1)
            ORDER  BY u.usr_id
            LIMIT  1)
         ELSE x.usr_id
       END
      ,x.usr
FROM   x;

Generic INSERT (take number from sequence):

INSERT INTO usr(usr) VALUES ('unspecial_guest');

-> sqlfiddle demo

Concurrency

If you need to worry about concurrency, you shouldn't be using this to begin with.
This setup is for a hand full of special cases.

Answer 3

I believe your problem has nothing to do with sequences. You can create a sequence that yields negative numbers. That way you can totally separate manual and auto identifers. But this doesn't solve your problem because you would still have to find the "next available number" among positive ids.

The solution also depends on the number of users. If you will only have 1000 users max. then you can determine the "next bigger available number" with a for loop. But if you are going to have 1 million users with random (manually given) identifiers, then the problem is not that easy.

I don't understand the concept here. Either they give a number manually, or they do not. If the number is already occupied, then why do you want to find the closest that is available? Why it is better then any another number returned by a sequence? I mean, if the manually entered number is already used, then you could just throw up an error message to the user. If the user does not insist on the given number, then any other number will do. Right?