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

From Pavel Stehule
Subject Re: proposal: function parse_ident
Date
Msg-id CAFj8pRCPN2Mi6k2t40Yexyxz6upnueigbCuyOCSdbKJwsvgrkw@mail.gmail.com
Whole thread Raw
In response to Re: proposal: function parse_ident  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


2015-08-20 2:22 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Jim Nasby <Jim.Nasby@bluetreble.com> writes:
>> 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...

Tables meet this naming spec.  Columns, functions, operators, operator
classes/families, collations, constraints, and conversions do not (you
need more data to name them).  Schemas, databases, languages, extensions,
and some other things also do not, because you need *less* data to name
them.  Types also don't really meet this naming spec, because you need to
contend with special cases like "int[]" or "timestamp with time zone".
So this proposal doesn't seem very carefully thought-through to me,
or at least the use case is much narrower than it could be.

Also, if "object does not exist" isn't supposed to be an error case,
what of "name is not correctly formatted"?  It seems a bit arbitrary
to me to throw an error in one case but not the other.

When I would to work with living object, then behave of cast to regclass is correct, but I can work with object, that will be created in future, and I need to take some other information about this future object - and then cast has to fail.

Regards

Pavel

 

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Declarative partitioning
Next
From: Simon Riggs
Date:
Subject: Re: Declarative partitioning