Re: Composite type: Primary Key and validation
От | Ron |
---|---|
Тема | Re: Composite type: Primary Key and validation |
Дата | |
Msg-id | 1ccdbfca-5c5d-2f20-bb53-9073ee9a0b21@gmail.com обсуждение исходный текст |
Ответ на | Re: Composite type: Primary Key and validation (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: Composite type: Primary Key and validation
|
Список | 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.
В списке pgsql-general по дате отправления: