Re: Castable Domains for different JSON representations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steve Chavez <steve(at)supabase(dot)io>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Castable Domains for different JSON representations
Date: 2023-06-25 16:24:01
Message-ID: 521213.1687710241@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Steve Chavez <steve(at)supabase(dot)io> writes:
> Currently domain casts are ignored. Yet this would be very useful for
> representing data in different formats such as json.

Hm. Usually what people ask for in this space is custom casts
*to* a domain type, which is problematic because it's not clear
how that should interact with the default behavior of promotion
to a domain (namely, applying any relevant domain constraints).
I'd also be suspicious of allowing custom casts from a domain
to any of its base types, because the assumption that that
direction is a no-op is wired into a lot of places. The
particular example you are proposing doesn't fall into either
of those categories; but I wonder if people would find it weird
if we allowed only other cases.

The bigger picture here, though, is what are you really buying
compared to just invoking the special conversion function explicitly?
If you have to write "sometsrangecolumn::mytsrange::json", that's
not shorter and certainly not clearer than writing a function call.
Admittedly, if the column is declared as mytsrange to begin with,
you can save one step --- but we smash domains to their base types
in enough places that I wonder how often you'd end up needing the
extra explicit cast anyway. And I don't think you'd want to tone
down that behavior, because anytime you use a domain column you
are going to be relying on it very heavily to avoid writing lots
of explicit casts to the base type. So I think this might prove
a lot less natural/transparent to use than you're hoping.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-06-25 17:03:37 Re: DROP DATABASE is interruptible
Previous Message Pavel Luzanov 2023-06-25 14:44:51 Re: psql: Add role's membership options to the \du+ command