Обсуждение: Unable to compare _bpchar for similarity in WHERE-clause (MINOR A NNOYANCE)

When I try to write an UPDATE where I include a WHERE-clause like:
[WHERE something='{"a","b","c"}], where something is a character[], i get
the errormessage:[Unable to identify an operator = for types '_bpchar and
'unknown' You will have to retype this query using an explicit cast]

The above statement works for text[]. Can you please provide an explanation
or if it just my query that is wrong, I would be happy.
                            Best regards,
                                  Nicolai Hansen

PS! I couldn't fill out your online form

Nicolai@ISYS.DK writes:
> When I try to write an UPDATE where I include a WHERE-clause like:
> [WHERE something='{"a","b","c"}], where something is a character[], i get
> the errormessage:[Unable to identify an operator = for types '_bpchar and
> 'unknown' You will have to retype this query using an explicit cast]
> The above statement works for text[].

Hmm.  Looks like there is a pg_operator entry for text[] = text[],
but none for bpchar[] = bpchar[].  This is an oversight, nothing more.
Feel free to add such an entry --- it can point to the same array-equals
function as the one for text[].

It's too late to fix this in the standard catalogs for 7.2, but I'll
make a note for 7.3.

            regards, tom lane

> Nicolai@ISYS.DK writes:
> > When I try to write an UPDATE where I include a WHERE-clause like:
> > [WHERE something='{"a","b","c"}], where something is a character[], i get
> > the errormessage:[Unable to identify an operator = for types '_bpchar and
> > 'unknown' You will have to retype this query using an explicit cast]
> > The above statement works for text[].
>
> Hmm.  Looks like there is a pg_operator entry for text[] = text[],
> but none for bpchar[] = bpchar[].  This is an oversight, nothing more.
> Feel free to add such an entry --- it can point to the same array-equals
> function as the one for text[].
>
> It's too late to fix this in the standard catalogs for 7.2, but I'll
> make a note for 7.3.

Added to TODO:

    * Add bpchar array comparison

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Added to TODO:
>     * Add bpchar array comparison

Varchar and very probably other ones are missing too.  Make it
    * Ensure we have array-eq operators for every built-in array type

            regards, tom lane

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Added to TODO:
> >     * Add bpchar array comparison
>
> Varchar and very probably other ones are missing too.  Make it
>     * Ensure we have array-eq operators for every built-in array type

Done.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Saturday 15 December 2001 03:06, Tom Lane wrote:
> Nicolai@ISYS.DK writes:
<snip>
>
> Hmm.  Looks like there is a pg_operator entry for text[] = text[],
> but none for bpchar[] = bpchar[].  This is an oversight, nothing more.
> Feel free to add such an entry --- it can point to the same array-equals
> function as the one for text[].
>
> It's too late to fix this in the standard catalogs for 7.2, but I'll
> make a note for 7.3.

Suitable for 7.2.1?

+ Justin

>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Justin <aa2@bigpond.net.au> writes:
> On Saturday 15 December 2001 03:06, Tom Lane wrote:
>> It's too late to fix this in the standard catalogs for 7.2, but I'll
>> make a note for 7.3.

> Suitable for 7.2.1?

Nyet.  We don't do initdbs for dot-releases.

Sometime in the future, it might be nice to devise a scheme that allows
additions to the system catalogs (as opposed to fundamental changes)
without an initdb.  But we haven't got it today.

            regards, tom lane

> On Saturday 15 December 2001 03:06, Tom Lane wrote:
> > Nicolai@ISYS.DK writes:
> <snip>
> >
> > Hmm.  Looks like there is a pg_operator entry for text[] = text[],
> > but none for bpchar[] = bpchar[].  This is an oversight, nothing more.
> > Feel free to add such an entry --- it can point to the same array-equals
> > function as the one for text[].
> >
> > It's too late to fix this in the standard catalogs for 7.2, but I'll
> > make a note for 7.3.
>
> Suitable for 7.2.1?

Nope, only minor stuff or 7.2.X and this would be a system table change
anyway.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Mon, 17 Dec 2001, Tom Lane wrote:

> Justin <aa2@bigpond.net.au> writes:
> > On Saturday 15 December 2001 03:06, Tom Lane wrote:
> >> It's too late to fix this in the standard catalogs for 7.2, but I'll
> >> make a note for 7.3.
>
> > Suitable for 7.2.1?
>
> Nyet.  We don't do initdbs for dot-releases.

But whouldn't a patch script be enough for this change? A few insert with
fixed oid commands would do it. No initdb needed, and the oid numbers
could be taken from what will be used for 7.3.

The script would need to make sure there isn't already something at that
oid, and that it hadn't been run already. But nothing should get inserted
with oids in the reserved space anyway. :-)

Take care,

Bill