Michael Meskes <[EMAIL PROTECTED]> writes:
> On Mon, Nov 10, 2008 at 08:12:49AM -0500, Tom Lane wrote:
>> Which direction are you hoping to go --- remove Iconst/Sconst, or use
>> them everywhere?

> For ecpg I don't care, I have to make some changes during translation anyway.
> Right now my script just sets both to ecpg_iconst. There is a small advantage
> in keeping Iconst/Sconst as it might save me a line or two in the script. As
> for the backend I would say that removing Iconst/Sconst make sense. These 
> rules
> just add an overhead, albeit a very small one. But still this advantage
> outweighs the very small scripting advantage. So yes, I'd remove 
> Iconst/Sconst. 

I experimented with doing this and found that things seemed noticeably
uglier; for example in createdb_opt_item we have (ignoring the actions)

            | TEMPLATE opt_equal name
            | TEMPLATE opt_equal DEFAULT
            | ENCODING opt_equal Sconst
            | ENCODING opt_equal Iconst
            | ENCODING opt_equal DEFAULT
            | COLLATE opt_equal Sconst
            | COLLATE opt_equal DEFAULT

which'd become

            | TEMPLATE opt_equal name
            | TEMPLATE opt_equal DEFAULT
            | ENCODING opt_equal SCONST
            | ENCODING opt_equal ICONST
            | ENCODING opt_equal DEFAULT
            | COLLATE opt_equal SCONST
            | COLLATE opt_equal DEFAULT

which at least to me seems confusing --- the ICONST and SCONST
occurrences look like literal keywords rather than token classes.
So I find I have a mild preference for the mixed-case spelling.

One possible way to shave the cycles and still have it look nice
is to rename the actual tokens produced by scan.l to Iconst and Sconst;
but this might be more trouble than it's worth.  Thoughts?

                        regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to