Re: proposal: function parse_ident - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: proposal: function parse_ident
Date
Msg-id 55D50F48.7000501@BlueTreble.com
Whole thread Raw
In response to Re: proposal: function parse_ident  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: function parse_ident  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 8/19/15 2:44 PM, Pavel Stehule wrote:
>     Don't say "parse names for things other than tables".  Only a minority
>     of the types of objects used in the database have names that meet this
>     specification.

Really? My impression is that almost everything that's not a shared 
object allows for a schema...

> I see one important reason and one minor reason:
>
> Important - cast to regclass is possible only for existing objects -
> parse_ident doesn't check validity of parsed ident.
> minor - cast to regclass depends on search_path - but parse_ident not -
> with this function I am able to detect if ident depends (or not) on
> search_path.

I've been forced to write this several times. I'd really like to expose 
this functionality.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Tom Lane
Date:
Subject: Re: Badly broken logic in plpython composite-type handling