On 9/15/15 11:49 PM, Pavel Stehule wrote:
1. processing user input with little bit more comfort - the user doesn't need to separate schema and table
This is especially useful if you're doing anything that needs to dynamically work with different objects. I'd say about 80% of the time I'm doing this ::regclass is good enough, but obviously the object has to exist then, and ::regclass doesn't separate schema from name.
There's a number of other handy convenience functions/views you can create to interface with the catalog, none of which are rocket science. But you're pretty screwed if what you want isn't in the catalog yet. (On a side note, something my TODO is to restart pg_newsysviews as an extension, and then add a bunch of convenience functions on top of that... things like relation_info(regclass) RETURNS (everything in pg_class, plus other useful bits like nspname), and relation_schema(regclass) RETURNS regnamespace).
FWIW, the other function I've wanted in the past that's difficult to implement externally is parsing the arguments of a function definition. ::regprocedure kinda works for this, but it blows up on certain things (defaults being one, iirc). I've specifically wanted that capability for a function I wrote that made it easy to specify *everything* about a function in a single call, including it's permissions and a comment on the function. That may sound trivial, but it's a PITA to cut and paste the whole argument list into multiple REVOKE/GRANT/COMMENT on statements. Even worse, not all the options of CREATE FUNCTION are supported in those other commands, so often you can't even just cut and paste.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
