| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, amul sul <sulamul(at)gmail(dot)com> |
| Subject: | Re: Hash Functions |
| Date: | 2017-05-14 03:44:22 |
| Message-ID: | CA+TgmoZZJD2OviFo48yTgU+90dfHSVg5RpGcPC5i3D5Wsem5yg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, May 13, 2017 at 7:08 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> I seriously doubt that's true. A lot of more complex types have
> internal alignment padding and such.
True, but I believe we require those padding bytes to be zero. If we
didn't, then hstore_hash would be broken already.
> Consider e.g. something like
> jsonb, hstore, or postgis types - you *can* convert them to something
> that's unambiguous, but it's going to be fairly expensive.
I'm fuzzy on what you think we'd need to do.
> Essentially
> you'd have to something like calling the output function, and then
> hashing the result of that.
I really don't see why we'd have to go to nearly that length.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-05-14 03:47:39 | Re: Hash Functions |
| Previous Message | Craig Ringer | 2017-05-14 03:43:51 | Re: Latest Data::Dumper breaks hstore_plperl regression test |