Re: [HACKERS] [COMMITTERS] pgsql: Centralize definition of integer limits.
On 2015-04-02 10:42:58 -0400, Robert Haas wrote: On Tue, Mar 31, 2015 at 12:15 PM, Andres Freund and...@anarazel.de wrote: I'm tempted to just prefix our limits with PG_ and define them unconditionally, including appropriate casts to our types. I don't have a better idea. Will push that. I'd appreciate it if you could do this soon. I like to compile with -Werror, and this problem means I can't. Done. Sorry for not doing this sooner, I'm more or less having holidays right now. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Centralize definition of integer limits.
On Thu, Apr 2, 2015 at 11:54 AM, Andres Freund and...@anarazel.de wrote: On 2015-04-02 10:42:58 -0400, Robert Haas wrote: On Tue, Mar 31, 2015 at 12:15 PM, Andres Freund and...@anarazel.de wrote: I'm tempted to just prefix our limits with PG_ and define them unconditionally, including appropriate casts to our types. I don't have a better idea. Will push that. I'd appreciate it if you could do this soon. I like to compile with -Werror, and this problem means I can't. Done. Sorry for not doing this sooner, I'm more or less having holidays right now. Thanks. Sorry to interrupt your vacation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Centralize definition of integer limits.
On Tue, Mar 31, 2015 at 12:15 PM, Andres Freund and...@anarazel.de wrote: I'm tempted to just prefix our limits with PG_ and define them unconditionally, including appropriate casts to our types. I don't have a better idea. Will push that. I'd appreciate it if you could do this soon. I like to compile with -Werror, and this problem means I can't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Centralize definition of integer limits.
Hi, On 2015-03-30 21:50:09 +0200, Andres Freund wrote: I'm too fried from the redeye back from pgconf nyc to do anything complicated, but it seems quite possible to define int64/uint64 based the stdint.h types if available. And generally a good idea too. I guess I'll try that tomorrow; unless Andrew beats me to it. It's possible to do that, but it's not as trivial as I'd hoped. For one we'd need to include stdint.h in some places we don't today (postgres_ext.h), for another we'd need some uglyness to determine the correct printf modifier for int64_t (can't use PRId64 etc afaics). I'm tempted to just prefix our limits with PG_ and define them unconditionally, including appropriate casts to our types. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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
Re: [HACKERS] [COMMITTERS] pgsql: Centralize definition of integer limits.
On 2015-03-31 12:10:48 -0400, Tom Lane wrote: Andres Freund and...@anarazel.de writes: On 2015-03-30 21:50:09 +0200, Andres Freund wrote: I'm too fried from the redeye back from pgconf nyc to do anything complicated, but it seems quite possible to define int64/uint64 based the stdint.h types if available. And generally a good idea too. I guess I'll try that tomorrow; unless Andrew beats me to it. It's possible to do that, but it's not as trivial as I'd hoped. For one we'd need to include stdint.h in some places we don't today (postgres_ext.h), for another we'd need some uglyness to determine the correct printf modifier for int64_t (can't use PRId64 etc afaics). Yeah, I thought the printf strings would be the sticking point :-( I hacked things till it worked, but it seems fragile. Using Werror for the format string test and adding 'l' to the tested combination works, but... At the point where it basically worked the required changes already amounted to ~150 lines changed (excluding configure). Making that robust is more than I'm willing to do right now. I do think it'd generally not be a bad thing to base our types on the standard types if available. I'm tempted to just prefix our limits with PG_ and define them unconditionally, including appropriate casts to our types. I don't have a better idea. Will push that. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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
Re: [HACKERS] [COMMITTERS] pgsql: Centralize definition of integer limits.
Andres Freund and...@anarazel.de writes: On 2015-03-30 21:50:09 +0200, Andres Freund wrote: I'm too fried from the redeye back from pgconf nyc to do anything complicated, but it seems quite possible to define int64/uint64 based the stdint.h types if available. And generally a good idea too. I guess I'll try that tomorrow; unless Andrew beats me to it. It's possible to do that, but it's not as trivial as I'd hoped. For one we'd need to include stdint.h in some places we don't today (postgres_ext.h), for another we'd need some uglyness to determine the correct printf modifier for int64_t (can't use PRId64 etc afaics). Yeah, I thought the printf strings would be the sticking point :-( I'm tempted to just prefix our limits with PG_ and define them unconditionally, including appropriate casts to our types. I don't have a better idea. 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
