Re: transforms

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chapman Flack <jcflack(at)acm(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: transforms
Date: 2025-04-19 19:20:02
Message-ID: 36022.1745090402@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

BTW, there is another way in which the current rules for transform
application are not self-consistent. Postgres has three kinds of
container types: arrays, composites, and ranges. But the transform
code special-cases only arrays. I'd have thought that if the idea is
to specify transforms only for base types, then TRANSFORM FOR TYPE
ought to recurse into composites and list their field types in
protrftypes. It doesn't, but if you look at plpython it appears
that

(1) you can create a transform for a composite type and it will be
applied;
(2) if you don't, the code recurses to the fields and will apply
per-field-type transforms then.

plperl will effectively do (1) but not (2), if I'm reading it right.

Ranges are a bit odd in that their semantics are not just a collection
of element/field types, so it perhaps makes sense that we don't
attempt to apply base-type transforms to their contents. But it's
sure inconsistent that arrays and composites aren't handled more
nearly alike here.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2025-04-19 19:30:57 Re: Unicode full case mapping: PG_UNICODE_FAST, and standard-compliant UCS_BASIC
Previous Message Tom Lane 2025-04-19 19:03:20 Re: transforms