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
>
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 |