Never seen a *negative* OID before. This is a first-class "crime scene"!

>     ... attrelid=-1519044407::oid ...
>     ... rel.oid = -1519044407::oid ...

#Facts

###0.

    2^32 - 1519044407 = 2775922889

And we have verified that OID `2775922889` indeed exists in your DB. Tests:

    SELECT * FROM pg_class WHERE oid = 2775922889;
    SELECT * FROM pg_class WHERE oid = '-1519044407';
    SELECT * FROM pg_class WHERE relname = 'test_table';

###1.
[The manual about object identifier types:][1]

> The `oid` type is currently implemented as an unsigned four-byte integer. 

###2.
Postgres cast accepts *signed* integer anyway (!)

The Postgres I/O conversion from string literals, as well as the cast from `integer`currently (pg 12) accepts negative integer values / literals as input anyway. Seems to just binary coerce a signed four-byte integer to *unsigned four-byte integer* and vice versa. Worth keeping in mind at least.

These, oddly, work:

    test=# SELECT '-1519044407'::oid, '-1519044407'::int::oid;
        oid     |    oid     
    ------------+------------
     2775922889 | 2775922889

Leads to different representation when casting to `int` versus `bigint`:

    test=# SELECT (oid '2775922889')::int
    test-#      , (oid '2775922889')::bigint;
        int4     |    int8    
    -------------+------------
     -1519044407 | 2775922889  -- !!

###3.
[The manual on *Numeric Constants*][2]:

> Note that any leading plus or minus sign is not actually considered part of the constant; it is an operator applied to the constant.

###4.
The cast operator `::` [takes precedence][3] over the unary minus operator (`-`).

# Conclusions

###1.
I have never seen OID numbers in that range before, and I have been working with all kinds of big databases. **You have a problem in your DB.**

Either you are burning OID numbers at an insane rate - already 2.8 billion numbers. ~ 1.5 billion remain until OID wraparound. (Not sure how that affects system catalogs. So far I only dealt with transaction ID wraparound - in theory / preventing it.) Do you have any tables created with `WITH OIDS`? (Nobody should any more. The feature is deprecated and [removed in Postgres 12][4].)

Or somebody/something messed with your system catalogs.

###2.
**If the above query was generated by pgAdmin4, there is a serious bug**.

Maybe that did not surface, yet, as nobody had OIDs in that range in the system catalogs, yet?

Seems like it operates with the *integer* representation of OIDs, and pastes those as numeric literals by mistake in queries. A numeric literal would work: `'-1519044407'::oid`.

But this does **not**:

    -1519044407::oid 

**Because:**

 - 1. `1519044407` is taken as numeric literal and initially coerced to `integer`.
 - 2. The cast operator `::` takes precedence over the sign operator `-` and the integer is cast do the (wrong!!) `oid`.
 - 3. Finally, Postgres tries to apply the sign operator and, luckily, fails with the reported error message:

 >     ERROR:  operator does not exist: - oid at character 125

 If it would not fail there, serious nonsense might occur.

*db<>fiddle [here](https://dbfiddle.uk/?rdbms=postgres_12&fiddle=33a1bbcc2b79e98fab5e8fda58ef39ea)*

  [1]: https://www.postgresql.org/docs/current/datatype-oid.html
  [2]: https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS-NUMERIC
  [3]: https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-PRECEDENCE-TABLE
  [4]: https://www.postgresql.org/docs/12/release-12.html