Re: Composite type: Primary Key and validation

Thank's a lot, I'll take care of it.

Il giorno lun 5 giu 2023 alle ore 16:18 Ron <ronljohnsonjr(at)gmail(dot)com> ha
scritto:

> 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.
>
>
>

--
Domenico L.

per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]