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 would affects system catalogs. So far I only dealt with transaction ID wraparound - in theory.) 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**. Are you running the latest version? (Version 4.12 at the time of writing.)

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 faile 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