Skip Menu |
 

This queue is for tickets about the DBD-Pg CPAN distribution.

Report information
The Basics
Id: 64849
Status: rejected
Priority: 0/
Queue: DBD-Pg

People
Owner: Nobody in particular
Requestors: perl [...] evancarroll.com
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Get meta data from information_schema
Download (untitled) / with headers
text/plain 390b
I think a lot of this code could be greatly simplified if moved from digging into the catalog with multiple SELECTS to using one single query. http://www.alberton.info/postgresql_meta_info.html Seems to have a good compilation of meta-queries that could replaces things like the convoluted foreign_key_info sub -- Evan Carroll System Lord of the Internets http://www.evancarroll.com
Download (untitled) / with headers
text/plain 165b
https://gist.github.com/783197 for an example of foreign_key_info in one select statement. -- Evan Carroll System Lord of the Internets http://www.evancarroll.com
Download (untitled) / with headers
text/plain 975b
On Mon Jan 17 13:27:33 2011, ECARROLL wrote: Show quoted text
> I think a lot of this code could be greatly simplified if > moved from digging into the catalog with multiple SELECTS > to using one single query.
The reason we don't use information_schema, as far as I can remember and tell, is: 1. It doesn't cover all the cases 2. We can't guarantee it will exist 3. It's much slower Number one is not much of an argument, as we can address things on a case by case (or sub by sub) basis. Number 2 is weak but valid: the information_schema can be dropped, but pg_class cannot :) Number three is an important one: in my tests (some time ago, granted), using the catalogs directly was always faster than the views in information_schema, which while creating some smaller queries up front, create some pretty long and convoluted SQL once you unwind all the views. There may have been other reasons, but this is probably a topic for the dbdpg list to argue about: dbd-pg@perl.org


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.