paulsnar
commented
2 years ago Moving this upwards because right now the semantics are in an interim state where some usages are treated via Ds\Set and others are not. Worst case, it's fine to not even use hstore (unless it's broadly available and there's a proper procedure to ensure its extension always loaded) and just make sure that the tags are represented as a Set throughout the backend PHP code. If needed, database queries can be made against the array if it's at all possible to ignore the index; as long as the tag count isn't abominably high it should be fine.
Functionally, I don't see a reason why two different orderings of tags should be considered distinct. And yet the JSON API represents them within an array type which has an inherent ordering, primarily because JSON doesn't have an unordered list-like data structure (I guess it could be emulated with an object with dummy values but that seems like a bit much and also needlessly verbose.) The reliance on arrays for tag listing can cause problems (c.f.) so it's probably better to nip this in the bud and do tags as sets instead.
Simplest way to do this is via hstore (via) on the Postgres layer and a Ds\Set (with the Ds polyfill so that the native extension isn't a prerequisite) on the PHP side.
This in itself doesn't impact the JSON serialization for the API, though the doc should be revised to note that the order of tags within the array is inconsequential. (Or, alternatively, always return tags in ASCII order or whatever.)