Skip to content

Fix op type - #137

Open
gfphoenix78 wants to merge 1 commit into
apache:mainfrom
gfphoenix78:fix-op-type
Open

gfphoenix78 wants to merge 1 commit into
apache:mainfrom
gfphoenix78:fix-op-type

Conversation

@gfphoenix78

Copy link
Copy Markdown
Contributor

closes: #ISSUE_Number


Change logs

Describe your change clearly, including what problem is being solved or what document is being added or updated.

Contributor's checklist

Here are some reminders before you submit your pull request:

Both spellings remove the ambiguity, for the same reason: the tie was
between text || anynonarray, which reads the literal as text, and
anycompatiblearray || anycompatible, which reads it as an array, and
giving either side a type kills the array reading. But they do not land
on the same operator.

  'pg_manifest_'::text || paxtables.oid     text || anynonarray
  'pg_manifest_' || paxtables.oid::text     text || text

Casting the literal leaves one candidate only because the alternatives
need casts that do not exist -- there is no implicit oid-to-text, nor
integer-to-text for the fixtures -- so resolution succeeds by
elimination, and the surviving operator renders the right side through
its type output function. Casting the value instead makes both sides
text, and that wins on the earlier rule: it is the candidate with the
most exact input matches, settled before the type-category rules the
ambiguity turned on in the first place.

Prefer that. The operand whose type was ever in question is the value,
not the literal, so the cast reads as what it is -- this oid is being
rendered as part of a relation name -- and it keeps saying the right
thing if that column's type ever changes. The manifest layout's path
column is text today and the catalog layout's columns are already cast
explicitly, but neither is this file's to guarantee.

Restore the indentation of the continuation lines in the two IN lists
while here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant