save redundant code for pseudotype I/O functions
Here is a patch to refactor some of the I/O functions in pseudotypes.c
to save redundant code and reduce the number of distinct translatable
strings.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/27/16 11:49 PM, Peter Eisentraut wrote:
Here is a patch to refactor some of the I/O functions in pseudotypes.c
to save redundant code and reduce the number of distinct translatable
strings.
And here is the actual patch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Save-redundant-code-for-pseudotype-I-O-functions.patchtext/x-patch; name=0001-Save-redundant-code-for-pseudotype-I-O-functions.patchDownload+45-302
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 10/27/16 11:49 PM, Peter Eisentraut wrote:
Here is a patch to refactor some of the I/O functions in pseudotypes.c
to save redundant code and reduce the number of distinct translatable
strings.
Would it be better to use CppAsString and CppConcat instead of directly
using # and ##, for consistency with what we do elsewhere?
Otherwise, +1.
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
On 10/28/16 9:25 AM, Tom Lane wrote:
Would it be better to use CppAsString and CppConcat instead of directly
using # and ##, for consistency with what we do elsewhere?
I modeled this after several similar places in gin and tsearch code,
which use ##:
contrib/btree_gin/btree_gin.c
src/backend/tsearch/wparser_def.c
src/backend/utils/adt/tsvector_op.c
Do people prefer the macros over this?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers