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

Add the data types in contrib to pg_types #39

Closed
davidfetter opened this issue Sep 6, 2018 · 10 comments
Closed

Add the data types in contrib to pg_types #39

davidfetter opened this issue Sep 6, 2018 · 10 comments

Comments

@davidfetter
Copy link

Things like hstore come back as unknown. I can see not including stuff like this if PostgreSQL didn't officially ship it, but types created in contrib seems like a relatively small lift.

@machack666
Copy link
Collaborator

If they have a consistent/fixed OID, then it shouldn't be a problem, I would expect. Without looking at it, I'm not sure that's definitively the case. (ISTR it has the type/oid mapping hard-coded in the module, but it's been a while since I've looked.)

@davidfetter
Copy link
Author

If it's not fixed, is it reasonable to do catalog lookups based on EXTENSIONs found?

@machack666
Copy link
Collaborator

At what point? DBD::Pg connect? Cached per-handle? I would expect that this could fall apart unless you were caching/storing this info per DBH, as the same extension could have different OIDs depending on where you connected, so something simple like:

my $dbh1 = DBI->connect('dbi:Pg:dbname=database1', $user1, $pass1);
my $dbh2 = DBI->connect('dbi:Pg:dbname=database2', $user2, $pass2);

could introduce overhead both in connection time (if that's when we query/cache the data), or different/non-matching OIDs depending on the database/host queried (if we try to shared the data once per module initialization).

This is not to say that it'd be impossible, just there are real obstacles here.

@machack666
Copy link
Collaborator

Yeah, looking at the code, there's not really any way to do this dynamically; you could conceivably use pg_types without connecting to the database, and it is indeed a static struct in types.c.

@davidfetter
Copy link
Author

davidfetter commented Sep 6, 2018

pg_types_dynamic with a warning about the overhead? Caching per DBH seems reasonable. With slightly more effort, probably as a separate feature, pg_types_dyname->{when} could be specified.

@machack666
Copy link
Collaborator

What are you looking for specifically about that interface?

@machack666
Copy link
Collaborator

It would need to be created as a DBH-level method, not a global function.

@davidfetter
Copy link
Author

Oh, good point.

@davidfetter
Copy link
Author

Come to think of it, everything we've discussed here seems like a DBH-level matter. If people want common attributes for all DBH's in their space, they know how.

@machack666
Copy link
Collaborator

They are indeed free to query the system tables. :-) Some specific helper methods though might be nice, similar to ->table_info() and the like.

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

No branches or pull requests

2 participants