Re: proposal: function parse_ident

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