Re: proposal: function parse_ident

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: function parse_ident
Date: 2015-08-19 19:44:55
Message-ID: CAFj8pRA6qdNrjNNy09WZFHwPwV4WzjbKDXLWy-zV1Fvpyt1EYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

2015-08-19 21:33 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > I miss a functionality that helps with parsing any identifier to basic
> > three parts - database, schema, objectname. We have this function
> > internally, but it is not available for SQL layer.
>
> > FUNCTION parse_ident(IN ident text, OUT dbname text, OUT schemaname text,
> > OUT objectname text)
>
> What exactly would you do with this that would not be better done with,
> for example, regclass?
>
> 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.
>

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.

Regards

Pavel

>
> regards, tom lane
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc Mamin 2015-08-19 19:55:45 Re: Declarative partitioning
Previous Message Tom Lane 2015-08-19 19:33:23 Re: proposal: function parse_ident