array from a `setof text` and array constructed from string are failing to equate

Question

I have a function that returns setof text.

I have a pgtap test that compares two values using pgtap's is comparitor:

return next is(
      ARRAY(select shared_types()),
      '{"{level,field_lookup,field_data,levels_insert_return}"}',
      ' The shared types are as expected');

The test fails with an unusual looking reporting of the comparison:

#  have: {level,field_lookup,field_data,levels_insert_return}    +
#  want: {"{level,field_lookup,field_data,levels_insert_return}"}

I'm not sure how to interpret or, to the degree the different displays point to different types, how to cast one to the other.

Answer 1

The values being compared are "display"/string representations... Thus, changing the expected value to "whatever" the display representation of an array turns out to be, works. I had tried something similar prior to posting, but not strictly "as strings".

The following change produces the expected result:

return next is(
      ...,
      '{level,field_lookup,field_data,levels_insert_return}',
      ...;

Update

While the answer "worked", it's mostly because I was focused on how pgtap sometimes requires using string representations of non-text values to get the test to pass.

However, there are a couple of fixes that make much more sense. With a little more digging using raise notice '%', to_json(...);, I was able to "see more" of where I went astray. In particular, I may have created a nested array; no bueno.

The following match.

types1 := '{"purpose", "level", "field_lookup"}';
types2 := ARRAY(select shared_types());

The following is a more robust comparison of two arrays when I only care about the "set" feature, i.e., unique elements.

return next ok(
    types2 @> types1,
    ' No missing types');

return next ok(
    types2 <@ types1,
    ' No extra types');