Re: proposal: function parse_ident

On 2/11/16 1:27 AM, Pavel Stehule wrote:

    I editorialized the docs and some of the comments. In particular, I
    documented behavior of not truncating, and recommended casting to
    name[] if user cares about that. Added a unit test to verify that
    works. BTW, I saw mention in the thread about not truncated spaces,
    but the function *does* truncate them, unless they're inside quotes,
    where they're legitimate.


ok

I missed some of my edits. Updated patch with those in place attached.

    Also added test for invalid characters.

    I think "strict" would be more in line with other uses in code.
    There are currently no other occurrences of 'strictmode' in the
    code. There are loads of references to 'strict', but I didn't go
    through all of them to see if any were used as externally visible
    function parameter names.


I am sorry, I don't understand to this point. You unlike the name of
parameter "strictmode" ? Have you any proposal? Maybe "restrictive" ?

I would just call it strict. There's precedent for that in the code.

The almost all code +/- is related to human readable error messages. We
can move some code to separate static functions - read_quoted_ident,
read_unquoted_ident, but there will be some magic about parameters, and
the code will not be much better, than it is now.

What I'm saying is that most places that need to do de-quoting or similar just run a simple while loop and use an in_quote variable to track whether they're inside a quote or not. See backend/utils/adt/rowtypes.c line 199 for an example.

As I said, I don't have a strong opinion on it, so if you prefer it this way that's fine with me.

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