From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Zhang <david.zhang@highgo.ca>
cc: pgsql-hackers@postgresql.org
Subject: Re: ERROR: invalid input syntax for type circle
In-reply-to: <332c47fa-d951-7574-b5cc-a8f7f7201202@highgo.ca>
References: <332c47fa-d951-7574-b5cc-a8f7f7201202@highgo.ca>
Comments: In-reply-to David Zhang <david.zhang@highgo.ca>
	message dated "Mon, 06 Apr 2020 14:12:38 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25256.1586211397.1@sss.pgh.pa.us>
Date: Mon, 06 Apr 2020 18:16:37 -0400
Message-ID: <25257.1586211397@sss.pgh.pa.us>
Precedence: bulk

David Zhang <david.zhang@highgo.ca> writes:
> I got an error when I was trying to insert a circle using the syntax 
> (the 3rd one) specified in the latest document.

Hm.  Presumably, that has never worked, and we've had no complaints
to date.  I'm halfway inclined to treat it as a documentation bug
and remove the claim that it works.

> The patch based on tag "REL_12_2" is attached.

This patch looks extremely dangerous to me, because it'll allow "s"
to get incremented past the ending nul character ... and then the
code will proceed to keep scanning, which at best is useless and
at worst will end in a core dump.

What actually looks wrong to me in this code is the initial bit

    if ((*s == LDELIM_C) || (*s == LDELIM))
    {
        depth++;
        cp = (s + 1);
        while (isspace((unsigned char) *cp))
            cp++;
        if (*cp == LDELIM)
            s = cp;
    }

If the first test triggers but it doesn't then find a following
paren, then it's incremented depth without moving s, which seems
certain to end badly.  Perhaps the correct fix is like

    if (*s == LDELIM_C)
        depth++, s++;
    else if (*s == LDELIM)
    {
        /* If there are two left parens, consume the first one */
        cp = (s + 1);
        while (isspace((unsigned char) *cp))
            cp++;
        if (*cp == LDELIM)
            depth++, s = cp;
    }

			regards, tom lane