Thread: save redundant code for pseudotype I/O functions

save redundant code for pseudotype I/O functions

From
Peter Eisentraut
Date:
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



Re: save redundant code for pseudotype I/O functions

From
Peter Eisentraut
Date:
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

Attachment

Re: save redundant code for pseudotype I/O functions

From
Tom Lane
Date:
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



Re: save redundant code for pseudotype I/O functions

From
Peter Eisentraut
Date:
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