Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

col_is_pk variants #133

Open
decibel opened this issue Dec 16, 2016 · 2 comments
Open

col_is_pk variants #133

decibel opened this issue Dec 16, 2016 · 2 comments
Assignees
Labels

Comments

@decibel
Copy link
Collaborator

decibel commented Dec 16, 2016

There should also be (name, name, name) and (name, name, name[]) versions of col_is_pk. Those versions already exist for col_is_unique().

@fluca1978
Copy link
Contributor

I suspect col_is_pk( name, name, name) could clash with col_is_pk( name, name, text). How can you distinguish:
col_is_pk( 'public', 'foo', 'id' )
from
col_is_pk( 'foo', 'id', 'id is not pk' ); ?

fluca1978 added a commit to fluca1978/pgtap that referenced this issue Oct 2, 2018
This allows for the automatic overloading of the function, implementing
therefore the col_is_pk( name, name, name[] ) as requested in issue theory#133.

See issue theory#133.
@theory
Copy link
Owner

theory commented Oct 4, 2018

There are a few other examples of functions with potentially-conflicting signatures. In those cases, we suggest that some of the params be cast to avoid the conflicts. See the docs for has_sequence for an example. They say:

If you find that the function call seems to be getting confused, cast the sequence to the NAME type:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants