Add constraint checking functions and tests

[RampantDespair]

Implemented new functions for checking the existence of constraints in PostgreSQL: _has_constraint, has_constraint, and hasnt_constraint. These functions support both schema-qualified and unqualified table names, along with type and description parameters.

Additionally, added comprehensive tests for these functions in constraint.sql, ensuring they handle various scenarios correctly, including existence checks and type validation. Created expected output for the tests in constraint.out to verify functionality.

This update enhances the constraint validation capabilities of pgTAP, providing users with more robust testing options.

[RampantDespair]

@theory
This is ready for review.

[theory]

I'm a little confused. We already have _hasc() and the functions that use it. This appears to be a duplication. Is there something you need that's missing?

It also recreates the functions in the tests, which should not be necessary.

This looks like a bot-created change. Please don't submit machine-generated code. If there is a feature you need, please implement it or ask for it in an issue.

[RampantDespair]

I'm a little confused. We already have _hasc() and the functions that use it. This appears to be a duplication. Is there something you need that's missing?

I didn't know it existed, it's undocumented...

And in any case, it doesn't cover my use-case, which is:

        ok(
            EXISTS(
                SELECT FROM pg_constraint
                INNER JOIN pg_class ON pg_constraint.conrelid = pg_class.oid
                INNER JOIN pg_namespace ON pg_class.relnamespace = pg_namespace.oid
                WHERE
                    pg_namespace.nspname = 'schema'
                    AND pg_class.relname = 'table'
                    AND pg_constraint.conname = 'ck__something__something'
                    AND pg_constraint.contype = 'c'
                    AND pg_constraint.coninhcount = 0
            ),
            'Constraint ck__something__something' should exist'::TEXT
        ),

The has_check doesn't cover that either, it just checks whether a table has a check on it, isn't useful when there's more than one. Same goes for col_has_check.
The same goes for other constraint variations.

It also recreates the functions in the tests, which should not be necessary.

I can fix that.

This looks like a bot-created change. Please don't submit machine-generated code. If there is a feature you need, please implement it or ask for it in an issue.

I can redo the PR to build on top of _hasc because once again, I wasn't aware of it's existence. Does that sound good?

[RampantDespair]

@theory
Thoughts on these new checks?
It's now built upon _hasc, I kept the generic has_constraint and hasnt_constraint.
I also took the liberty of extending has_check, hasnt_check, has_fk, hasnt_fk, has_pk, hasnt_pk, has_unique and hasnt_unique.

I also added has_exclude and hasnt_exclude.
I could probably add your generic "does table have an exclude at all" for symmetry with the other checks.

And speaking of symmetry, I notice there wasnt any hasnt_check unlike for fk, pk and unique.
If you want I can add that as well.

Finally I also noted overlap problems which I suppose I'll need to resolve assuming you think this addition as a place in your project. Which didn't really seem to be the case from your first response, hopefully this fix changes that.

[theory]

Since we have the other constraint-checking functions, I don't think you need add public functions char argument. If the goal is to complement the existing constraint-checking functions by adding a name argument, do that.

[Reads some more]

Oh, I see you have those in the upgrade script. They need to be in pgtap.sql.in, too. All changed canonically go into that file; then dupe them in the upgrade script.

I guess I have no objection to also adding a generic has_constraint() script to which one can pass the constraint type char argument, since the others are there, too. Yes, adding hasnt_check() would also be welcome (unless it creates some kind of conflict).

Please also add documentation to doc/pgtap.md and tests for all of the new functions.

[RampantDespair]

Oh, I see you have those in the upgrade script. They need to be in pgtap.sql.in, too. All changed canonically go into that file; then dupe them in the upgrade script.

Appended at the bottom, or alongside next of kin (to maintain structure)?

IE:
has_pk
has_pk
has_pk
[new_]has_pk
etc.

[RampantDespair]

Okay this is ready for another round of feedback / review.
Pending questions:

• What are your thoughts on the overlaps present in the has/hasnt tests documented here 27dbf34 (this PR)
• And what are the guidelines when editing pgtap.sql.in, is it append-only? or should I place stuff where it most makes sense in terms of consistency and structure?

[RampantDespair]

@theory Any news?

[theory]

I'm traveling, so only working on stuff like this occasionally. Might be a few weeks before I get back to it. Apologies.