Re: Composite type: Primary Key and validation

Consider applying "database normalization" to the schema so that the columns
are only in one table, and then pass around synthetic keys.

On 6/5/23 10:06, Lorusso Domenico wrote:
> Thank's, you are right, I've the same doubts.
> A composite type is useful because I've to add all these information on
> many tables and because it more easy to pass all these informations to
> functions that have to ensure the right format and evaluation.
>
> Talking about first point I could use the "table inheritance", but I've to
> reset all constraints for each table :-(
>
> Il giorno lun 5 giu 2023 alle ore 16:02 Laurenz Albe
> <laurenz(dot)albe(at)cybertec(dot)at> ha scritto:
>
> 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.
>
> Yours,
> Laurenz Albe
>
>
>
> --
> Domenico L.
>
> per stupire mezz'ora basta un libro di storia,
> io cercai di imparare la Treccani a memoria... [F.d.A.]

--
Born in Arizona, moved to Babylonia.