[HACKERS] warning in code while building on windows
1.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101: 'isnull' : unreferenced local variable It seems this variable is used only under macro USE_ASSERT_CHECKING, so it is better to declare under this macro only. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- 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] [PATCH] pg_sleep(interval)
True. I think the gripe here is that pg_sleep('42') has worked for
many releases now,
Maybe it could still work if pg_sleep(TEXT) is added as well?
--
Fabien.
--
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] Chinese in Postgres
[ Could you please trim your citations, i.e., please don’t top-post: https://en.wikipedia.org/wiki/Posting_style#Top-posting ] 2013/8/16 Francesco ciifrance...@tiscali.it: Thanks for your answer. Yes, the client is also UTF8: MyDB=# show client_encoding; client_encoding - UTF8 (1 row) I guess that this is the client encoding used by psql. I suspect your C++-program doesn’t use client encoding UTF8. What library are you using, libpq? Did you run the psql instance (whose output you pasted) on Windows or on some kind of UNIX-machine over SSH? Does your problematic C++-program run on Windows or the UNIX-machine? (The “client encoding” is not a property of the database, but of the specific client you are using. The C++-program’s client encoding might therefore by entirely different from the one used by psql, especially if you don’t run them on the same machine.) [ BTW, I think this question really doesn’t belong on -hackers, as no-one seems to think it is a bug, nor is it a question about PostgreSQL internals. ] Nicolas -- A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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] Feature Request on Extensions
On 08/17/2013 11:53 PM, Steven Citron-Pousty wrote: Greetings all: I spoke to Josh B and company at OSCON about a feature we really need for PostgreSQL extensions on OpenShift (Red Hat's Platform as a Service). What we need is the ability for Postgresql to load extensions from a users file space. There were objections earlier against loading anything binary from a directory not being writable by root only. But allowing loading modules from the directory of the user the server runs as (usually postgres, but could be any system user other than root) seems like a really good idea. I can not see how this would create any additional security problems, as the user can already do anything that user can do. adding postgresql binary in this mix running as the same user can not possibly add any new security concerns. If anybody can point out something I overlook here, please do so! Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ
[HACKERS] CREATE FUNCTION .. SET vs. pg_dump
Hi all! While working on upgrading the database of the search system on postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on that system are actually invalid and cannot be reloaded without being hacked on manually... Simple way to reproduce is using the following: CREATE TEXT SEARCH CONFIGURATION pg ( PARSER = pg_catalog.default ); CREATE FUNCTION test() RETURNS INTEGER LANGUAGE sql SET default_text_search_config TO 'public.pg' AS $$ SELECT 1; $$; once you dump that you will end up with an invalid dump because the function will be dumped before the actual text search configuration is (re)created. I have not checked in any more detail but I suspect that this problem is not only affecting default_text_search_config. Stefan -- 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] Feature Request on Extensions
On 08/18/2013 11:36 AM, Hannu Krosing wrote: On 08/17/2013 11:53 PM, Steven Citron-Pousty wrote: Greetings all: I spoke to Josh B and company at OSCON about a feature we really need for PostgreSQL extensions on OpenShift (Red Hat's Platform as a Service). What we need is the ability for Postgresql to load extensions from a users file space. There were objections earlier against loading anything binary from a directory not being writable by root only. But allowing loading modules from the directory of the user the server runs as (usually postgres, but could be any system user other than root) seems like a really good idea. I can not see how this would create any additional security problems, as the user can already do anything that user can do. adding postgresql binary in this mix running as the same user can not possibly add any new security concerns. To be extra sure no additional security is breached, CREATE EXTENSION could add check that the client requesting this is also the same user connected locally via ident authentication when requesting loading binary modules from this users (who is running both postgresql binary and client) owned filespace. -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ
[HACKERS] LO interface
Hello is any specific reason why permissions are checked in top lo_* API and not in inv_* API? I am trying to write extension for bytea - LO conversions, but It is not possible without code duplication due placing a permission check in top API. Regards Pavel
[HACKERS] pgbench / compatibility with old(er) releases
Hi, I'm running some tests comparing benchmarks on a range of versions, going back to 8.0 (mostly because of curiosity, but actually for practical reasons too). I've decided to use the pgbench from 9.3, mostly to make the results more comparable and because of features not available in older releases (aggregation of transaction log, number of threads, ...), but this causes issues on old releases because of features not available in the really old releases - I've found these, so far: (a) specifying fillfactor in CREATE TABLE (b) DROP TABLE IF EXISTS (c) application_name used for the connection I do understand the versions up to 8.3 are unsupported (or soon will be), but I think it's handy to be able to run current pgbench on those versions. So I propose to: (a) add --no-fillfactor that actually disables adding it to the CREATE TABLE (now it adds default 100) (b) add --no-appname that disables adding it to the connection (BTW why not to allow custom appname? I'm thinking about multiple pgbench instances running at the same time, or so, but on second thought I've never done that.) (c) do not use IF EXISTS but do that the old way (check if the table exists in a separate command) Opinions? Objections? regards Tomas -- 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] CREATE FUNCTION .. SET vs. pg_dump
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes: While working on upgrading the database of the search system on postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on that system are actually invalid and cannot be reloaded without being hacked on manually... CREATE TEXT SEARCH CONFIGURATION pg ( PARSER = pg_catalog.default ); CREATE FUNCTION test() RETURNS INTEGER LANGUAGE sql SET default_text_search_config TO 'public.pg' AS $$ SELECT 1; $$; once you dump that you will end up with an invalid dump because the function will be dumped before the actual text search configuration is (re)created. I don't think it will work to try to fix this by reordering the dump; it's too easy to imagine scenarios where that would lead to circular ordering constraints. What seems like a more workable answer is for CREATE FUNCTION to not attempt to validate SET clauses when check_function_bodies is off, or at least not throw a hard error when the validation fails. (I see for instance that if you try ALTER ROLE joe SET default_text_search_config TO nonesuch; you just get a notice and not an error.) However, I don't recall if there are any places where we assume the SET info was pre-validated by CREATE/ALTER FUNCTION. 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
Re: [HACKERS] pgbench / compatibility with old(er) releases
Tomas Vondra t...@fuzzy.cz writes: I do understand the versions up to 8.3 are unsupported (or soon will be), but I think it's handy to be able to run current pgbench on those versions. So I propose to: (a) add --no-fillfactor that actually disables adding it to the CREATE TABLE (now it adds default 100) (b) add --no-appname that disables adding it to the connection (BTW why not to allow custom appname? I'm thinking about multiple pgbench instances running at the same time, or so, but on second thought I've never done that.) (c) do not use IF EXISTS but do that the old way (check if the table exists in a separate command) Opinions? Objections? TBH this seems like way too much cruft to be added in support of what are after all *unsupported* releases. And how far back do we stop, anyway? I'd suggest you test all the branches with the newest pgbench version that happens to work with the oldest branch you care about. Having said that, it seems like (a) could be fixed with about a one-line change, if we simply made it not add the with (fillfactor=%d) clause when fillfactor was at 100. And I'm not clear why (b) is a problem; libpq already takes care of suppressing application_name when connecting to old servers. 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
Re: [HACKERS] Feature Request on Extensions
Steven Citron-Pousty spou...@redhat.com writes: What we need is the ability for Postgresql to load extensions from a users file space. TBH this needs a whole lot of thought. I'm prepared to grant that there may be other useful security models besides the one we currently have, but we need to be sure that anything we offer as an alternative is secure on its own terms and well-thought-out. The main problem that I'm having with the idea ATM is that I don't see how we could allow any such capability to non-superusers; isn't the ability to load chosen code into the server tantamount to superuserdom? If we restrict it to superusers, and the capability is only effective for the current session, that seems like it will lead directly to people running their whole application as superuser. Which is a place we don't want to end up at, no matter what the security model is. So I think that you've underspecified a user --- there needs to be some separation between users who have the ability to create/activate extensions and users who can use those extensions. I know that under a typical server install scenario this would be a bad from a security perspective, but on OpenShift we runs things differently. Let me explain what happens when a developer creates an application on OpenShift: Right offhand, it seems like you have or could grant a developer superuser/DBA privileges with respect to his own PG instance, so I'm not actually seeing why you have a problem. What exactly is stopping him from installing his extension in the normal way? 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
Re: [HACKERS] pgbench / compatibility with old(er) releases
On 18.8.2013 17:54, Tom Lane wrote: TBH this seems like way too much cruft to be added in support of what are after all *unsupported* releases. And how far back do we stop, anyway? I'd suggest you test all the branches with the newest pgbench version that happens to work with the oldest branch you care about. That won't give me the 9.3-only features (that I really want/need). Having said that, it seems like (a) could be fixed with about a one-line change, if we simply made it not add the with (fillfactor=%d) clause when fillfactor was at 100. And I'm not Yeah, that seems line a nice solution - no additional option. Another solution is to use custom scripts, and only use pgbench to execute them. That'd solve the IF EXISTS problem too. clear why (b) is a problem; libpq already takes care of suppressing application_name when connecting to old servers. Hmmm, I'm getting this in the log (when connection to 8.0.0): FATAL: unrecognized configuration parameter application_name but it seems to be working. I'm wondering if FATAL is appropriate here. Tomas -- 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] CREATE FUNCTION .. SET vs. pg_dump
On 08/18/2013 05:40 PM, Tom Lane wrote: Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes: While working on upgrading the database of the search system on postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on that system are actually invalid and cannot be reloaded without being hacked on manually... CREATE TEXT SEARCH CONFIGURATION pg ( PARSER = pg_catalog.default ); CREATE FUNCTION test() RETURNS INTEGER LANGUAGE sql SET default_text_search_config TO 'public.pg' AS $$ SELECT 1; $$; once you dump that you will end up with an invalid dump because the function will be dumped before the actual text search configuration is (re)created. I don't think it will work to try to fix this by reordering the dump; it's too easy to imagine scenarios where that would lead to circular ordering constraints. What seems like a more workable answer is for CREATE FUNCTION to not attempt to validate SET clauses when check_function_bodies is off, or at least not throw a hard error when the validation fails. (I see for instance that if you try ALTER ROLE joe SET default_text_search_config TO nonesuch; you just get a notice and not an error.) hmm yeah - just throwing a NOTICE with check_function_bodies=off seems like reasonable workaround to this problem area. Not sure it would be required to turn it into a NOTICE in general, though alter role/alter database seems like an established precedence for this. Stefan -- 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] Fix Windows socket error checking for MinGW
On 08/17/2013 01:16 AM, Noah Misch wrote: On Fri, Aug 16, 2013 at 06:56:45PM -0500, Michael Cronenworth wrote: I started a thread on the general list so read that for more info. http://www.postgresql.org/message-id/520a6e55.40...@cchtml.com I'm also going to submit the patch to CommitFest. +#ifndef WIN32 if (SOCK_ERRNO == EWOULDBLOCK) +#else + if (SOCK_ERRNO == WSAEWOULDBLOCK) +#endif Thanks for looking into this. I suspect this patch is achieving the right runtime behavior, but some cleanup is in order. src/include/port/win32.h makes some effort to preempt the need for a patch like this, but the relevant code isn't used for MinGW: /* * For Microsoft Visual Studio 2010 and above we intentionally redefine * the regular Berkeley error constants and set them to the WSA constants. * Note that this will break if those constants are used for anything else * than Windows Sockets errors. */ #if _MSC_VER = 1600 #pragma warning(disable:4005) #define EMSGSIZE WSAEMSGSIZE #define EAFNOSUPPORT WSAEAFNOSUPPORT #define EWOULDBLOCK WSAEWOULDBLOCK #define EPROTONOSUPPORT WSAEPROTONOSUPPORT #define ECONNRESET WSAECONNRESET #define EINPROGRESS WSAEINPROGRESS #define ENOBUFS WSAENOBUFS #define ECONNREFUSED WSAECONNREFUSED #define EOPNOTSUPP WSAEOPNOTSUPP #pragma warning(default:4005) #endif I suspect we should do one of the following: 1. Redefine those constants for more (all?) compilers. 2. Remove that block and put #ifdef around all usage of such constants in frontend code, as you have done. 3. Remove that block and make src/backend/port/win32/socket.c frontend-usable, so frontend code can treat errno like backend code treats errno. What do you recommend? Thanks, nm There is a much simpler fix, which is to do these assignments unconditionally in src/port/win32.h. The following small change fixes the problem for me: diff --git a/src/include/port/win32.h b/src/include/port/win32.h index 3a68ea4..5b93220 100644 --- a/src/include/port/win32.h +++ b/src/include/port/win32.h @@ -278,9 +278,8 @@ typedef int pid_t; #ifndef EAFNOSUPPORT #define EAFNOSUPPORT WSAEAFNOSUPPORT #endif -#ifndef EWOULDBLOCK +#undef EWOULDBLOCK #define EWOULDBLOCK WSAEWOULDBLOCK -#endif #ifndef ECONNRESET #define ECONNRESET WSAECONNRESET #endif Note that the original patch appears to be not only misguided but wrong, in that it undid a recent important change (commit a099482c) as I read it. cheers andrew -- 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] Feature Request on Extensions
Hi, I had the chance to being at OSCON this year and had a chat with the Open Shift team while there. Thanks for posting your use case! Tom Lane t...@sss.pgh.pa.us writes: Right offhand, it seems like you have or could grant a developer superuser/DBA privileges with respect to his own PG instance, so I'm not actually seeing why you have a problem. What exactly is stopping him from installing his extension in the normal way? They use the same binary installation for everyone, and an OS packaged one at that. Which means that there's a single `libdir` and `pkglibdir` shared globally on the system. And no individual user has any privileges down there as it's a global OS location. What they want is to be able to run the same binary for every user, yet have a personal `libdir` place where to load extension's .so files from, and point that to a place owned by the initdb bootstrap superuser, different each time. The easiest way for them here would be for this parameter to be a fully dynamic setting, second best an initdb option, IIUC. The way they make that secure in their model is by using modern approaches to security, or at least modern enough that we don't get to envision those offerings when we usually talk about the idea of allowing the backend to load non-root-owned binary modules: SElinux and CGroups. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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] warning in code while building on windows
Amit Kapila escribió: 1.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101: 'isnull' : unreferenced local variable It seems this variable is used only under macro USE_ASSERT_CHECKING, so it is better to declare under this macro only. We have a macro for this, PG_USED_FOR_ASSERTS_ONLY. This should silence it; if the msvc stuff is not picking it up then maybe we need to tweak the definition of the macro somehow. -- Álvaro Herrerahttp://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] Materialized views WIP patch
Kevin Grittner kgri...@ymail.com wrote: Noah Misch n...@leadboat.com wrote: Also, could you explain the use of RelationCacheInvalidateEntry() in ExecRefreshMatView()? CacheInvalidateRelcacheByRelid() followed by CommandCounterIncrement() is the typical pattern; this is novel. I suspect, though, neither is necessary now that the relcache does not maintain populated status based on a fork size reading. Yeah, that was part of the attempt to support unlogged materialized views while also not returning bogus results if the view had not been populated, using heap file size. I agree that this line can just come out. If there are no objections real soon now, I will remove it in master and the 9.3 branch before the release candidate. Done. -- Kevin Grittner EDB: 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] warning in code while building on windows
On 08/18/2013 05:08 PM, Alvaro Herrera wrote: Amit Kapila escribió: 1.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101: 'isnull' : unreferenced local variable It seems this variable is used only under macro USE_ASSERT_CHECKING, so it is better to declare under this macro only. We have a macro for this, PG_USED_FOR_ASSERTS_ONLY. This should silence it; if the msvc stuff is not picking it up then maybe we need to tweak the definition of the macro somehow. The macro is pretty gcc-specific, isn't it? For MSVC we would probably need to surround the declaration with something like these lines. #pragma warning(disable:4101) #pragma warning(default:4101) cheers andrew -- 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] Feature Request on Extensions
On 08/18/2013 10:20 PM, Dimitri Fontaine wrote: Hi, I had the chance to being at OSCON this year and had a chat with the Open Shift team while there. Thanks for posting your use case! Tom Lane t...@sss.pgh.pa.us writes: Right offhand, it seems like you have or could grant a developer superuser/DBA privileges with respect to his own PG instance, so I'm not actually seeing why you have a problem. What exactly is stopping him from installing his extension in the normal way? They use the same binary installation for everyone, and an OS packaged one at that. Which means that there's a single `libdir` and `pkglibdir` shared globally on the system. And no individual user has any privileges down there as it's a global OS location. What they want is to be able to run the same binary for every user, yet have a personal `libdir` place where to load extension's .so files from, and point that to a place owned by the initdb bootstrap superuser, different each time. The easiest way for them here would be for this parameter to be a fully dynamic setting, second best an initdb option, IIUC. The way they make that secure in their model is by using modern approaches to security, or at least modern enough that we don't get to envision those offerings when we usually talk about the idea of allowing the backend to load non-root-owned binary modules: SElinux and CGroups. Even without SELinux I can not immediately see the security weakening when you allow the backend to load .so-s from directories which are owned by the user both the client and the backend runs as. so say there is system user 'bob' who has his own instance of database initdb-ed in /home/bob/pgsql and running as user bob, with bob also being the main superuser for the cluster. User bob can then CREATE EXTENSION which loads .so-s from /home/bob/libpgsql and if a more restricted user is needed for web client database access then bob can do CREATE USER lesserbob; for this. I think this is something that should be secure even with standard non-SELinux install. Feel free to point out where a security escalation is possible with such a use case. Regards, -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- 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] warning in code while building on windows
Andrew Dunstan escribió: On 08/18/2013 05:08 PM, Alvaro Herrera wrote: Amit Kapila escribió: 1.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101: 'isnull' : unreferenced local variable It seems this variable is used only under macro USE_ASSERT_CHECKING, so it is better to declare under this macro only. We have a macro for this, PG_USED_FOR_ASSERTS_ONLY. This should silence it; if the msvc stuff is not picking it up then maybe we need to tweak the definition of the macro somehow. The macro is pretty gcc-specific, isn't it? For MSVC we would probably need to surround the declaration with something like these lines. #pragma warning(disable:4101) #pragma warning(default:4101) That seems pretty difficult to do with the position we've chosen for the macro. -- Álvaro Herrerahttp://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] warning in code while building on windows
Andrew Dunstan and...@dunslane.net writes: Amit Kapila escribió: 1.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101: 'isnull' : unreferenced local variable The macro is pretty gcc-specific, isn't it? If that's the problem, why isn't Amit seeing a boatload of similar warnings elsewhere? 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
Re: [HACKERS] 9.3 release notes suggestions
From: 'Bruce Momjian' [mailto:br...@momjian.us] On Tue, Aug 13, 2013 at 05:59:05PM +0900, Etsuro Fujita wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. One small suggestion: listitem para Allow link linkend=SQL-CREATEFOREIGNDATAWRAPPERforeign data wrappers/link to support writes (inserts/updates/deletes) on foreign tables (KaiGai Kohei) /para /listitem This is the in-core functionality, so ISTM it would be better that this is stated in the section of Object Manipulation rather than in that of Additional Modules. Please find attached a patch. Agreed, done. Thanks! I have another small suggestion about the recent changes in 9.3 release notes. I think it would be better that a headline feature is listed without its author. Please find attached a patch. Thanks, Best regards, Etsuro Fujita release-9.3.patch Description: Binary data -- 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] warning in code while building on windows
On Mon, Aug 19, 2013 at 9:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Amit Kapila escribió:
1.\src\backend\utils\cache\relfilenodemap.c(213) : warning C4101:
'isnull' : unreferenced local variable
The macro is pretty gcc-specific, isn't it?
If that's the problem, why isn't Amit seeing a boatload of similar
warnings elsewhere?
If I try to change other place similar to relfilenodemap.c, I am
getting similar warning. For example:
Original Code
ExecMaterial()
{
..
/*
* Allocate a second read pointer to serve as the mark. We know it
* must have index 1, so needn't store that.
*/
int ptrnoPG_USED_FOR_ASSERTS_ONLY;
ptrno = tuplestore_alloc_read_pointer(tuplestorestate,
node-eflags);
Assert(ptrno == 1);
..
}
Modified Code
-
ExecMaterial()
{
..
/*
* Allocate a second read pointer to serve as the mark. We know it
* must have index 1, so needn't store that.
*/
int ptrnoPG_USED_FOR_ASSERTS_ONLY;
#ifdef USE_ASSERT_CHECKING
ptrno = tuplestore_alloc_read_pointer(tuplestorestate,
node-eflags);
Assert(ptrno == 1);
#endif
..
}
After above modification it gives below compilation error:
1.\src\backend\executor\nodeMaterial.c(69) : warning C4101: 'ptrno' :
unreferenced local variable
Coming to original warning, changing the code as below removes warning:
RelidByRelfilenode()
{
..
#ifdef USE_ASSERT_CHECKING
if (assert_enabled)
{
Oid check;
bool isnull PG_USED_FOR_ASSERTS_ONLY;
check = fastgetattr(ntp, Anum_pg_class_reltablespace,
RelationGetDescr(relation),
isnull);
Assert(!isnull check == reltablespace);
check = fastgetattr(ntp, Anum_pg_class_relfilenode,
RelationGetDescr(relation),
isnull);
Assert(!isnull check == relfilenode);
}
#endif
Moving isnull declaration inside if block resolves current compilation
warning, I think in any case it is better to declare inside if block
as it is used in that block only.
I think resolving the bigger problem such that it should not give
warning for such usage in MSVC is important, but can be dealt as a
separate thread/patch.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
