Is the decision for merging AIDs to int8 definitive? about pg_diffix HOT 6 CLOSED

Same idea would work for contributions. We can have a union of known contribution types and functions which work on each of those.

from pg_diffix.

We always did that. It is simpler and more efficient. So the question I see is why should we do it otherwise now?
We don't need bijection for anonymization. We also need to hash the values in the end so we can compute the seed.
Getting rid of macros would be just a bonus.

The more opaque explain is a drawback, but to find the actual AID back one could use:

select aid from table where hash(aid) = hash_value

from pg_diffix.

So the question I see is why should we do it otherwise now?

No strong opinion. The argument was that if it's relatively cheap to maintain then why not...

I'll continue as planned.

from pg_diffix.

Same idea would work for contributions.

That is a more nuanced discussion, as the various types are not equivalent with one another for all purposes.
In the AID case, things look more straight-forward to me.

from pg_diffix.

We also lose the nice explain features which could be a debugging and teaching utility.

One could also see this as a feature: if the AID is a name, email or phone number, one would never want that exposed directly to the analyst or system administrator. Showing the hash in debug utilities would reduce this likelihood.

The argument was that if it's relatively cheap to maintain then why not...

In my experience, things have a way of interacting in unforeseen ways. I think it pays to cull code aggressively. Especially when it comes to dealing with strings in C.

from pg_diffix.

if the AID is a name, email or phone number, one would never want that exposed directly to the analyst or system administrator.

Yes, in fact these aggregates won't be callable at all in sensitive tables. Maybe only as a superuser or special role if we decide later, or we'll drop them completely in the future.

I think it pays to cull code aggressively.

Okay, I agree. Let's simplify.

from pg_diffix.