Re: small cleanup: unify scanstr() functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: small cleanup: unify scanstr() functions
Date
Msg-id 1044817.1601565552@sss.pgh.pa.us
Whole thread Raw
In response to small cleanup: unify scanstr() functions  (John Naylor <john.naylor@2ndquadrant.com>)
Responses Re: small cleanup: unify scanstr() functions  (John Naylor <john.naylor@2ndquadrant.com>)
List pgsql-hackers
John Naylor <john.naylor@2ndquadrant.com> writes:
> In the attached, the GUC_scanstr() function body is moved to scansup.c
> to replace scanstr(), but with a different order of if-statements to
> make the diff smaller. Since we have control over what goes in the BKI
> file, we can use single-quoted escape strings there, allowing removal
> of special case code for double quotes.

I'm unsure this topic is worth messing with.  But if we do so, I'd kind
of like to move scanstr() out of parser/scansup.c.  Since it's not used
by the core scanner, only bootstrap, it seems out of place there; and
it's confusing because somebody coming across it for the first time
would reasonably assume that it does have something to do with how
we lex normal SQL strings.

Of course, that just begs the question of where to put it instead.
But since guc-file.l lives in utils/misc/, in or beside that file
does not seem that awful.

We might consider renaming it to something a shade less generic, too.
I have no immediate suggestions on that score.

In short: maybe instead of what you have here, leave GUC_scanstr()
alone except for a possible rename; make bootscanner.l use that;
and drop the now-unused scanstr().

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away
Next
From: Konstantin Knizhnik
Date:
Subject: Should walsernder check correctness of WAL records?