Re: Lookup tables

From: Thiemo Kellner <thiemo(at)gelassene-pferde(dot)biz>
To: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Lookup tables
Date: 2025-02-04 21:41:38
Message-ID: 64603f36-b6d5-469b-8d6d-30376842241b@gelassene-pferde.biz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-support pgsql-general

04.02.2025 18:31:09 Michał Kłeczek <michal(at)kleczek(dot)org>:

>
>> On 4 Feb 2025, at 18:27, Thiemo Kellner <thiemo(at)gelassene-pferde(dot)biz> wrote:
>>
>>  Unless the lookup table is actually a check constraint one can use to populate dropdown boxes in an interface.
>
> That is even worse because it ceases being transactional and users might select something different than what they see on the screen.

I might see what you want to point out. E.g. the table is COLOURS. The rec with id 1 is RED, the one with id 2 is BLUE, 3 is GREE and so on. Now you load these values into the dropdown box that sports RED, BLUE, GREE and so on. While someone selects GREE, there is a maintenance release changing GREE to YELLOW. So when that someone sends the selection by id to the backend, not GREE is selected but YELLOW.

A) Your release changed the sementics of the record 3. It's meaning changed. I cannot recommend doing that.
B) If you absolutely must change the semantic, put your application into maintenance mode in which noone can select anything beforehand.

If the maintenance would just correct the typo from GREE to GREEN, nothing would happen. Yor customer still ordered the lavishly green E-Bike her hear ever desired.

In response to

Responses

Browse pgadmin-support by date

  From Date Subject
Next Message Karsten Hilbert 2025-02-04 21:44:19 Re: Lookup tables
Previous Message Rich Shepard 2025-02-04 20:57:34 Re: Lookup tables [FIXED]

Browse pgsql-general by date

  From Date Subject
Next Message Karsten Hilbert 2025-02-04 21:44:19 Re: Lookup tables
Previous Message Ron Johnson 2025-02-04 21:12:49 Re: old OS