Re: Implement a new data type - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Implement a new data type
Date
Msg-id 629844.1597421389@sss.pgh.pa.us
Whole thread Raw
In response to Implement a new data type  (mohand oubelkacem makhoukhene <mohand-oubelkacem@outlook.com>)
List pgsql-hackers
mohand oubelkacem makhoukhene <mohand-oubelkacem@outlook.com> writes:
> I would like to implement a new data type next to char, number, varchar... for example a special "Money" type, but
> I don't want to use extensions and the Create type command.  I want to implement it directly inside source code,
> because I want to implement my new type at lower level, in order to perform some more sophisticated functions after.

Why, and exactly what do you think you'd accomplish?

Postgres is meant to be an extensible system, which in general means that
anything that can be done in core code could be done in an extension.
Admittedly there are lots of ways that we fall short of that goal, but
new data types tend not to be one of them.  The only big difference
between an extension datatype and a core one is that for a core type
you have to construct all the catalog entries "by hand" by making
additions to the include/catalog/*.dat files, which is tedious and
error-prone.

> Just as an example,  help the optimizer in its decisions.

The core optimizer is pretty darn data-type-agnostic, and should
remain so IMO.  There are callbacks, such as selectivity estimators
and planner support functions, that contain specific knowledge of
particular functions and data types; and those facilities are available
to extensions too.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Ibrar Ahmed
Date:
Subject: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits
Next
From: Bruce Momjian
Date:
Subject: Re: EDB builds Postgres 13 with an obsolete ICU version