This is the definition of vendor lock in; the more you use embedded non-standard functionality of a product the less likely it is that you'll ditch it.
As long as you're aware of what you're doing it's fine. And you're documenting your usage, right?
If you don't write your database layer with vendor-specific features and optimizations in mind, you're definitely leaving tons of performance on the floor. Multi-DB support for a largely identical schema is a fool's errand.
It's not Postgres's fault that MySQL is comparatively bereft of modern features.
• transactional DDL
• RETURNING clause
• unfettered use of user-defined functions
• a native UUID type
• the ability to define custom data types and domains
• DDL triggers
• row-level security
• actual arrays and booleans
• MERGE
• range types and constraints
• IP address and CIDR types
• partial indexes
• LATERAL JOIN
MS SQL has temporal table support, the ability to integrate any .Net functionality directly into the database, pivot tables, etc.
It's really hard to explain to lifelong MySQL users what they've been missing in the name of database agnosticism. Using the lowest common denominator to all the engines feels like wearing a straitjacket attached to lead weights.
Not sure the word "vendor" is exactly correct when using standard PostgreSQL functionality though, as PostgreSQL has multiple vendors providing that functionality. So, not really "vendor lock in".
The term is clearly correct for databases with only one vendor though (Oracle, etc).
As long as you're aware of what you're doing it's fine. And you're documenting your usage, right?