Re: parray_gin and \d errors in PG10

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: parray_gin and \d errors in PG10
Date: 2017-10-22 19:13:47
Message-ID: 28947.1508699627@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> On Sun, Oct 22, 2017 at 02:36:12PM -0400, Tom Lane wrote:
>> ... Possibly we could use
>> (stxkind @> '{d}'::pg_catalog."char"[])
>> That works for me without parray_gin installed, but I wonder whether
>> it fails due to ambiguity if you do have parray_gin installed.

> [ yup ]

Bleah.

One option is to use OPERATOR(pg_catalog.@>), which aside from being
really ugly, isn't a complete fix because it still wouldn't work if
someone had decided to install parray_gin into the pg_catalog schema.

Or maybe what we should do is to avoid @> in favor of using

('d' = any(stxkind))

That's a bit less nice because it doesn't generalize as cheaply to
looking for multiple stxkind values, but since this query has no
current need for that, maybe it's fine.

Anyway, the fact that this is such a mess points up why trying to
alias polymorphic operators isn't such a hot idea. parray_gin
really ought to get rid of that operator.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Arthur Zakirov 2017-10-22 19:15:31 Re: How to get login user name and host name in pgaudit
Previous Message Justin Pryzby 2017-10-22 18:41:14 Re: parray_gin and \d errors in PG10