Re: [GENERAL] Concurrency-safe Replacing a Set of Rows (Without SERIALIZABLE)

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [GENERAL] Concurrency-safe Replacing a Set of Rows (Without SERIALIZABLE)
Дата
Msg-id CAKFQuwZKPAHdKxpBM-9Qy+AFd8Vvr0tNeB5VXq5FNp-+7J+n3Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Concurrency-safe Replacing a Set of Rows (Without SERIALIZABLE)  (Gavin Wahl <gwahl@fusionbox.com>)
Список pgsql-general
On Wed, Apr 12, 2017 at 3:56 PM, Gavin Wahl <gwahl@fusionbox.com> wrote:
> Given this limited example I'd probably choose to model notifications as an
> array on the user table.  Then just "UPDATE user SET notifications =
> array['a','b']::text WHERE user_id = 1;

I'm hesitant to ditch the first normal form just to get around this. Anyway,
there's actually extra data in the table that makes it hard to use an array:

CREATE TABLE notifications (
  user_id INT,
  type CHAR(1),
  threshold INT,
  some_options BOOLEAN,
  PRIMARY KEY (user_id, type)
);

​A custom composite type would solve that part of the problem.

You're going to have to pick you poison here.  No serializable, no locking, and no atomic data type.  I don't have any other reasonable ideas that aren't any worse than any one of those three.  You would need to introduce some kind of "notification set id" and make (user_id, active_notification_set_id) the linking multi-column key.

Or wait and see if anyone more clever than I has some ideas.

David J.

В списке pgsql-general по дате отправления:

Предыдущее
От: Gavin Wahl
Дата:
Сообщение: Re: [GENERAL] Concurrency-safe Replacing a Set of Rows (Without SERIALIZABLE)
Следующее
От: John R Pierce
Дата:
Сообщение: Re: [GENERAL] Error During PostGIS Build From Source on Linux