On Sun, May 21, 2017 at 11:01:57PM -0400, Chapman Flack wrote:
> ? A transformOpclassLike function could verify that foo and the opcintype
> of int4_ops have the same typlen and typbyval, and that the operators and
> support procs are backed by C functions, and return a list of
> CREATE OPERATOR re
On 05/22/17 18:39, Alvaro Herrera wrote:
> Chapman Flack wrote:
>> CREATE INDEX ON foo USING btree ( bar, baz ALSO quux );
>
> INCLUDING:
> https://www.postgresql.org/message-id/56168952.4010...@postgrespro.ru
I'd buy that.
-Chap
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
Chapman Flack wrote:
> That was what gave me the idea in the first place, which then
> I realized could be more generally useful. If I could say
> something like
>
> CREATE INDEX ON foo USING btree ( bar, baz ALSO quux );
>
> so that only bar and baz are compared in insertion and search,
> but q
On 05/22/2017 05:16 AM, Amit Kapila wrote:
> Agreed, but even if we have any such syntax, making it work for hash
> indexes is tricky, because we currently store the hash code in the
> index, not the original hash index key.
That was what gave me the idea in the first place, which then
I realized
On Mon, May 22, 2017 at 8:31 AM, Chapman Flack wrote:
> On 05/19/17 11:41, Tom Lane wrote:
>
>> No, nobody's done anything about allowing hash indexes to support
>> uniqueness AFAIK. I don't have a clear picture of how much work
>> it would be, but it would likely be more than trivial effort;
>
>
On 05/19/17 11:41, Tom Lane wrote:
> No, nobody's done anything about allowing hash indexes to support
> uniqueness AFAIK. I don't have a clear picture of how much work
> it would be, but it would likely be more than trivial effort;
I see what you mean. Because of the way hash values are ordered
Chapman Flack writes:
> Was my guess about the reason right? Does this PG10 announcement
> also mean it will be possible to use UNIQUE constraints with some
> pure-identifier, no-natural-ordering type that supports only hashing?
No, nobody's done anything about allowing hash indexes to support
un
Hi,
The item on hash indexes reminded me of an old comment from years
ago that I put in the code of the first custom PG datatype I ever
built at $work:
COMMENT ON OPERATOR CLASS puid_ops USING btree IS
'As puids are only identifiers, there is no obvious reason to define
ordering operators or supp
