fix(db): Resolve the execution table through search_path in the revision guard

The guard added in #924 tested information_schema against
current_schema(), which is only the first entry in search_path. On a
connection whose search_path puts another schema first, an execution
table in a later schema makes the predicate false while the unqualified
ALTER below it resolves to that same later table, so the widening is
skipped without a word and execution.revision silently stays integer.

Resolve the relation with to_regclass and read its type from
pg_attribute, so the guard and the ALTER always agree on which table
they are talking about. to_regclass returns NULL when no execution table
is reachable at all, which leaves the guard false as before.

Reported by the cubic review bot on #924, after that PR had merged.

Signed-off-by: Prasanth Baskar <prasanth@8gears.com>

Author: bupd

make/migrations/postgresql/harbor_next.sql

@@ -138,13 +138,19 @@ WHERE m.id = ranked.id AND m.rank <> ranked.rn;
 -- Guarded on the current type so repeat runs never rewrite the table.
 DO $$
 BEGIN
+    -- Resolve the schema from the same relation the unqualified ALTER below
+    -- resolves to. current_schema() is only the first entry in search_path, so
+    -- it would miss an execution table living in a later one and skip the
+    -- widening without a word. to_regclass returns NULL when there is no
+    -- execution table at all, which leaves the guard false, as it should.
     IF EXISTS (
         SELECT 1
-        FROM information_schema.columns
-        WHERE table_schema = current_schema()
-          AND table_name = 'execution'
-          AND column_name = 'revision'
-          AND data_type <> 'bigint'
+        FROM pg_attribute a
+        WHERE a.attrelid = to_regclass('execution')
+          AND a.attname = 'revision'
+          AND a.attnum > 0
+          AND NOT a.attisdropped
+          AND a.atttypid <> 'bigint'::regtype
     ) THEN
         ALTER TABLE execution ALTER COLUMN revision TYPE bigint;
     END IF;