Improved col_is{nt}_X implementation

[RampantDespair]

Closes #363 [1/3]

As discussed this is the first part of the PR split -> implementation symmetry.

All 3 now follow:

-- col_is{nt}_X( schema, table, column[], description ) -- ( NAME, NAME, NAME[], TEXT )
-- col_is{nt}_X( schema, table, column[] )              -- ( NAME, NAME, NAME[] )
-- col_is{nt}_X( table, column[], description )         -- ( NAME, NAME[], TEXT )
-- col_is{nt}_X( table, column[] )                      -- ( NAME, NAME[] )
-- col_is{nt}_X( schema, table, column, description )   -- ( NAME, NAME, NAME, TEXT )
-- col_is{nt}_X( schema, table, column )                -- ( NAME, NAME, NAME )
-- col_is{nt}_X( table, column, description )           -- ( NAME, NAME, TEXT )
-- col_is{nt}_X( table, column )                        -- ( NAME, NAME )

EDIT: col_is_null isn't in scope because you went the is/not instead of is/isnt so I didn't think it was pertinent. If you disagree I can conform it as well I suppose.

[theory]

EDIT: col_is_null isn't in scope because you went the is/not instead of is/isnt so I didn't think it was pertinent. If you disagree I can conform it as well I suppose.

No, I think it's the same, it's just named differently because SQL has a NOT NULL expression.

[RampantDespair]

@theory Understood, I'll conform it right now, one moment

[theory]

Adding this means existing use of col_isnt_pk ( NAME, NAME, TEXT ) may no longer work unless or until users cast that final argument. IOW, this would fail:

SELECT col_isnt_pk( 'x', 'y', 'z');

They'll have to instead use one of these two:

SELECT col_isnt_pk( 'x', 'y', 'z'::name);
SELECT col_isnt_pk( 'x', 'y', 'z'::text);

Which will be confusing because the types don't really tell you much.

[theory]

Oh, so the existing tests, which don't cast the third argument, still pass? Okay then it seems like it will be backward compatible after all.

[theory]

Because of this, please follow the example of functions like col_is_unique() and add a note like this for each function that may now have ambiguity:

If you omit the description for the 3-argument version, you'll need to cast
the table and column parameters to the `NAME` data type so that PostgreSQL
doesn't resolve the function name as a description. For example:

```sql
SELECT col_is_pk( 'myschema', 'sometable'::name, 'pk_name'::name );

[theory]

Also: Please use the 50/72 rule in the commit message.

[theory]

@theory Understood, I'll conform it right now, one moment

Sorry, don't know what this responds to.