Re: Add ZSON extension to /contrib/
От | Stephen Frost |
---|---|
Тема | Re: Add ZSON extension to /contrib/ |
Дата | |
Msg-id | 20210526004911.GW20766@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Add ZSON extension to /contrib/ (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add ZSON extension to /contrib/
Re: Add ZSON extension to /contrib/ |
Список | pgsql-hackers |
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. Thanks, Stephen
Вложения
В списке pgsql-hackers по дате отправления: