On 5/26/21 2:49 AM, Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
>>> I like the idea of the ZSON type, but I'm somewhat disappointed by its
>>> current limitations:
>>
>> I've not read the code, so maybe this thought is completely off-point,
>> but I wonder if anything could be learned from PostGIS. AIUI they
>> have developed the infrastructure needed to have auxiliary info
>> (particularly, spatial reference data) attached to a geometry column,
>> without duplicating it in every value of the column. Seems like that
>> is a close analog of what's needed here.
>
> Err, not exactly the same- there aren't *that* many SRIDs and therefore
> they can be stuffed into the typemod (my, probably wrong, recollection
> was that I actually pushed Paul in that direction due to being
> frustrated with CHECK constraints they had been using previously..).
>
> Not something you could do with a dictionary as what's contempalted
> here. I do agree that each jsonb/zson/whatever column should really be
> able to have its own dictionary though and maybe you could shove *which*
> of those dictionaries a given column uses into the typemod for that
> column... In an ideal world, however, we wouldn't make a user have to
> actually do that though and instead we'd just build our own magically
> for them when they use jsonb.
>
I think doing this properly will require inventing new infrastructure to
associate some custom parameters with a column (and/or data type). In
principle it seems quite similar to 911e702077, which introduced opclass
parameters, which allowed implementing the new BRIN opclasses in PG14.
Even if we eventually decide to not add zson into contrib (or core), it
seems like this infrastructure would make zson more usable in practice
with this capability.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
