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