Re: Composite type: Primary Key and validation

From: Ron <ronljohnsonjr(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Composite type: Primary Key and validation
Date: 2023-06-05 14:17:49
Message-ID: 1ccdbfca-5c5d-2f20-bb53-9073ee9a0b21@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 6/5/23 09:02, Laurenz Albe wrote:
> On Mon, 2023-06-05 at 11:49 +0200, Lorusso Domenico wrote:
>> I've a couple of questions about composite type.
>> Suppose this composite type:
>> CREATE TYPE my_type AS (
>>     user_ts_start My_start_timestamp,
>>     user_ts_end My_end_timestamp,
>>     db_ts_start My_start_timestamp,
>>     db_ts_end My_end_timestamp,
>>     audit_record jsonb
>> );
>> My_start_timestamp is a domain of timestamp with default as now().
>> My_end_timestamp is a domain of timestamp with default as infinite
>>
>>    1. May I use user_ts_start and/or db_ts_start has part of Primary Key of a table that contains a field of my_type?
>>    2. to add an overall check constraint on the entire composite type, could be a valid
>> approach to create a domain based on my_type and add a custom function to validate it? (check_my_type(VALUE)).
>> In this way I've a dominan of composite type that contain others domain... what do you think?
> Avoid using composite types as data types for a table column.
> It adds complexity for no clear gain.

Isn't now() also a bad idea, since it's the "now" at the start of the
transaction?

Better to use clock_timestamp().

--
Born in Arizona, moved to Babylonia.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Lorusso Domenico 2023-06-05 14:53:56 Re: Is there any good optimization solution to improve the query efficiency?
Previous Message Laurenz Albe 2023-06-05 14:02:12 Re: Composite type: Primary Key and validation