Re: [HACKERS] WIP: About CMake v2
Michael Paquier wrote: src/include/port/win32.h:#define putenv(x) pgwin32_putenv(x) and my MSVC2015 drop down here because pgwin32_putenv has wrong signature. I hope it is not true now. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Mark Kirkwood wrote: Yeah, there seems to be a lot of these. Looking through them almost all concern the addition of piece of code to wrap putenv. e.g: I made this small wrapper special for MSVC 2015 without Service Packs because postgres macross were in conflict with MS internal functions. After some time and some updates for MSVC Michael Paquier could not reproduce my problem but I keep this patch to avoid problems in the future. I can check old behavior again and revert all changes if needed and ofcourse I have plans to make separate patch for this changes. Thanks! -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Mark Kirkwood wrote: Actually, it was not that tricky to separate out the cmake only changes, and test this on unmodified sources. It appears to work fine for me - passes 'make check' (needs the v1_1 incremental patch applied of course). The Patch is attached. I wonder if the original had some changes for building under latest Windows...(I'm using Ubuntu 16.10, with cmake 3.5). Thanks for all your works! Can you make push request here: https://github.com/stalkerg/postgres_cmake I have rebased (merge) to master and make other important fix. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Craig Ringer wrote: So personally I think it'd be fine if a cmake build defaulted to finding and using what it could, but offered a --minimal mode or whatever that gets us just core postgres + whatever we enable explicitly. But our current behaviour is OK too. To me it's best way. But I'm not sure what Tom Lane will accept this. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Craig Ringer wrote: So personally I think it'd be fine if a cmake build defaulted to finding and using what it could, but offered a --minimal mode or whatever that gets us just core postgres + whatever we enable explicitly. But our current behaviour is OK too. To me it's best way. But I'm not sure what Tom Lane will accept this. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Tom Lane wrote: So this is really not open for negotiation. As Peter said upthread, what we are looking for in a CMake reimplementation is that it behaves exactly like the Autoconf version does. To the extent that you are unable or unwilling to duplicate that behavior, you increase the odds that we'll reject this work. Who asking about negotiation? I just wanted an explanation for the clear understanding and nothing more. Now I know about reasons. Thanks. regards -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Hello. Peter Eisentraut wrote: I tried this out. Because of some file moves in initdb and pg_basebackup, the build fails: Yes, I need rebase patch to latest master. I do it as soon as possible. Also I have some new achievements. I suggest you use git format-patch to produce patches. This is easier to apply, especially when there are a lot of new files involved. Also use the git facilities to check for whitespace errors. I agree. I suggest for now you could put this into a README.cmake file in your patch. We don't need to commit it that way, but it would help in the meantime. Good idea, currently I write all documentation on github. I will try to move it to patch. When I run cmake without options, it seems to do opportunistic feature checking. For example, it turns on OpenSSL or Python support if it can find it, otherwise it turns it off. We need this to be deterministic. Without options, choose the basic feature set, require all other features to be turned on explicitly, fail if they can't be found. Whatever the Autoconf-based build does now has been fairly deliberately tuned, so there should be very little reason to deviate from that. This approach I see only in Postgres project and not fully understood. Can you explain me more what reasons led to this approach? Not big deal to make behavior like postgres Autoconf but I think it's important clear view here. The Python check appears to be picking up pieces from two different Python installations: Ooops you right. For Python detecting I use standard CMake module and his behavior depending on CMake version. We should really careful here. The check results otherwise look OK, but I'm a bit confused about the order. It checks for some functions before all the header files are checked for. Is that intentional? I have plans to change order checks. There are a number of changes in .[ch] and .pl files that are unclear and not explained. Please explain them. You can also submit separate preliminary patches if you need to do some refactoring. Ultimately, I would expect this patch not to require C code changes. I suppose separate patches with comments will be best way. I will do it. I think we can talks about details after that. Big thanks for your remarks it's very important for me and this "small" project. I will try to do all tasks quickly. Best regards. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
Robert Haas wrote: Yeah, I don't know. For my money, decorating the function definitions in place seems easier than having to maintain a separate export list, especially if it can be hidden under the carpet using the existing stupid macro tricks. But I am not a Windows expert. I suppose we should to establish politics for this case. Because any who see this and who have experience in Windows surprised by this. For windows any DLL it is like plugins which must use strict API for communications and resolving symbols. The situation is that in Postgres we have not API for extensions in the Windows terms. In future CMake will hide all this troubles in itself but if tell in truth I don't like this situation when any extension has access to any non-static symbols. However time to time we meet static function that we want to reusing in our extension and today I know only one decision - copy-paste. Without strict politics in this case we will be time to time meet new persons who ask this or similar question. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
17 октября 2016 г. 23:42:30 MSK, Tom Lane wrote: [ wanders away wondering what cmake does with this... ] CMake can export all symbols using only one setting - WINDOWS_EXPORT_ALL_SYMBOLS for shared libraries and special for Postgres I made "export all" for executable files. You can try this in cmake-3.7.0-rc1. Current postgres_cmake is using the modified gendef.pl (use only stdin/stdout for objtool without any files). regards, Yury -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Stas Kelvich wrote: Tried to generate Xcode project out of cmake, build fails on genbki.pl: can't locate Catalog.pm (which itself lives in src/backend/catalog/Catalog.pm) Thanks again! I have corrected your issue. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Stas Kelvich wrote: On 17 Sep 2016, at 20:21, Yury Zhuravlev <u.zhurav...@postgrespro.ru> wrote: Michael Paquier wrote: ... Tried to generate Xcode project out of cmake, build fails on genbki.pl: can't locate Catalog.pm (which itself lives in src/backend/catalog/Catalog.pm) Can you try again? On my Xcode 7.3 / ElCapitan everything is working correctly. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] File system operations.
On четверг, 15 сентября 2016 г. 19:09:16 MSK, Tom Lane wrote: Robert Haas <robertmh...@gmail.com> writes: On Thu, Sep 15, 2016 at 11:01 AM, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote: What do you think about moving stuff from pg_upgrade/file.c to storage/file/ to allow reuse of this code? I think it'll be really helpful for developers of contrib modules like backup managers. Well, storage/file is backend and pg_upgrade is frontend. If you want to reuse the same code for both it's got to go someplace else. Also, to the extent that it's important to use those wrappers rather than libc directly, it's because the wrappers are tied into backend resource management and error handling conventions. I don't see how you convert that into code that also works in a frontend program, or what the point would be exactly. Maybe we should towards to framework ecosystem. I mean, developers of third party tools must use maximum same api what in backend. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Andres Freund wrote: It's way too likely that we end up releasing with multiple buildsystems that way. If we fail in the CMake integration we can easily remove all CMake files before code freeze. I hope step by step CMake integration better way for current situation. But I do not insist, just I trying to find the easiest way. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Michael Paquier wrote: Your patch recommends to build with cmake after creating build/, now I would expect most users to run cmake from the root folder. However this causes all the Makefiles to get overwritten. As supporting all platforms at once with cmake is going to be uncommitable, we are going to need both methods able to live together for a while. Well, they can coexist with this patch as long as cmake is not run from the root of the code tree, which is acceptable for me as long as the switch is not completed. However others may think differently on the matter. It's really a good point. Forbidden run cmake from root it is better decision for me (of course for start). Instead of getting support for all existing platforms, I would recommend as well focusing only on one platform for the time being, Linux, and get the work done correctly for that first. Once there is something committed, we will be able to patch the buildfarm, and get machines to switch to cmake one by one. After those are switched, we could extend that. You mean in first version of patch I can focus on Linux systems? Another point of contention is support for extensions. How long should we keep support for the existing PGXS? How external extensions would compile with the new thing infrastructure? As long as possible. I hope I can make PGXS Makefiles generator. Which brings me to another point, your patch is focused on features, meaning that per-OS checks are all grouped by feature, but it may be a good idea to split checks by OS if necessary, with for example per-platform files and scripts in cmake/os/. And we could have just something for Linux now. Currently I do not have a lot OS specific tests. All checks are doing in same manner. - root's .gitignore needs to add entries for CMakeFiles and cmake_install.cmake. You need as well to ignore CMakeCache Thanks I done this in last commit. - A couple of headers are generated, like cubeparse.h (?) Because BISON generate header by default. I suppose author of cube launched bison by hand but I made it automatic. - Currently a lot of users do things like that: cd src/test/regress/ && make check But this patch breaks that, and that's not cool. Recovery tests in src/test/regress won't run either. It seems restriction by design because in CMake you have only one enter point. That's all I have for now. Looking forward to seeing some progress here. I merged master to my branch and I spent time to porting all changes. I hope send patch in the weekend without terrible flaws. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Michael Paquier wrote: Could it be possible to get a refreshed patch on this thread for at least the sake of the archives? I'd really like to see somehting happening here and do some progress for this CF. Sure, I will do it on Friday. Today I finished mingw+msys support. (mingw without msys has not passed some tests) -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Suggestions for first contribution?
Christian Convey wrote: Yury doesn't seem to need help with CMake Hello. I am sorry that the only answer is now. I need help but with write CMake code: 1. Make ecpg tests 2. Make MinGW/Msys support 3. many many ... all targets and discussion here: https://github.com/stalkerg/postgres_cmake/issues If you can only test CMake for Ubuntu x86_64 that it is not necessary. If I not fully understand you - sorry. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Why is a newly created index contains the invalid LSN?
Jim Nasby wrote: Yeah, especially since you mentioned this being for backups. I suspect you *want* those WAL records marked with 0, because that tells you that you can't rely on WAL when you back that data up. Thanks, you right if you doing incremental backup you try compare every page LSN with last backup LSN. For my page tracking system (ptrack) it is secondary cheks but for classic pg_arman algorithm it is main approach. If Invalid LSN will be realy sign of broken page header it help for third-party applications. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Why is a newly created index contains the invalid LSN?
Amit Kapila wrote: On Thu, Aug 25, 2016 at 7:55 PM, Yury Zhuravlev <u.zhurav...@postgrespro.ru> wrote: Hello hackers. I have a small question. While working on an incremental backup I noticed a strange thing. Newly created index is contains the invalid LSN (0/0). Exmaple: ... For some of the indexes like btree which are built outside shared buffers, we don't write WAL unless wal_level >= REPLICA. I think Robert has explained it very well how we handle the crash recovery situation for such indexes. However, for some other indexes which don't bypass shared buffers like BRIN, GIN we do write WAL for such cases as well, so you must see LSN for those type of indexes. I am less sure, if there will be any problem, if don't write WAL for those indexes as well when wal_level < REPLICA. Thanks all. Now understand LSN strongly connected with WAL. However how difficult put last system LSN instead 0? It's not so important but will allow make use LSN more consistent. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Why is a newly created index contains the invalid LSN?
Hello hackers.
I have a small question. While working on an incremental backup I noticed a
strange thing.
Newly created index is contains the invalid LSN (0/0).
Exmaple:
postgres=# select lsn from page_header(get_raw_page('test_a_idx2',0));
lsn
-
0/0
(1 row)
Can you explain me why?
Thanks.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres 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] WIP: About CMake v2
Stefan Kaltenbrunner wrote: well we have for example a NetBSD 5.1 boxe (coypu) on the buildfarm that have a software stack that is basically 2008/2009ish... So 2.8.0-2.8.3 seems like a realistic target to me still You can install fresh CMake to NetBSD without big problems from source. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Andres Freund wrote: The benefit cmake brings to the table, from my pov, is that it allows to get rid of somewhat a parallel buildsystem (msvc / windows, which sources most of its information from the makefiles). If we continue to have two, especially if they're entirely separate, I see little benefit in this whole endeavor. I fully agree with this. Although I still leave the probability that for a while (couple of months) CMake will coexist with autoconf solely for testing and verification. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Stefan Kaltenbrunner wrote: On 08/18/2016 09:30 PM, Christian Convey wrote: Hi Karl, I'll need to let Yury answer your original question regarding the best way to report CMake-related bugs. Regarding the errors you're getting... I just looked at CMake's online documentation regarding your "target_compile_definitions" ... Well - "too old" is a relative term - cmake 2.8.10 was released in only october 2012 and cmake 2.8.11 in may 2013 so it is not even 4 years old, the oldest currently supported (though for not much longer) postgresql release 9.1 was released in september 2011 and 9.2 was also released before october 2012. So while Cmake compat might only make it for v10, I dont think that we can depend on bleeding edge version like that for our buildtools... 1. I don't know but nobody objections if we install latest CMake under Windows or MacOSX but many if under Linux/*BSD. I have builded CMake recently under old Solaris without any problems. 2. I use "graceful degradation" method and currently target is 3.0 version BUT time to time I testing and backporting the code. I hope I can make all features for 2.8.4 . 3. Please do not compare cmake and GNU Make. CMake it's like Autotools with detect library scripts out the box. Every new version brings not only new functions and syntax construction. Most fix in find_library scripts. Besides you can't build project without gnu make, make, nmake, ninja and etc because CMake generate files for another make systems. On this basis, to CMake can not meet the same requirements for version as GNU Make. It is quite another thing. PS Special for Postgres in CMake 3.6 I implemented features for replace gen_def.pl script under MSVC. https://gitlab.kitware.com/cmake/cmake/merge_requests/29 -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Christian Convey wrote: I'm interested in helping with your CMake effort. I don't have any experience contributing to PG, but I do have some free time at the moment. Please let me know if I can help. I glad to hear it. I suppose you can just try build postgres and send all problems to github tracker. https://github.com/stalkerg/postgres_cmake/issues Big thanks! -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Stefan Kaltenbrunner wrote: hmm how do you actually want reports on how it works? I just played with it on spoonbill (OpenBSD 5.3/sparc64) and got this: CMake Error at CMakeLists.txt:1250 (file): file does not recognize sub-command GENERATE CMake Error at src/port/CMakeLists.txt:156 (target_compile_definitions): Unknown CMake command "target_compile_definitions". -- Configuring incomplete, errors occurred! there is also a ton of stuff like: Make Error: Internal CMake error, TryCompile generation of cmake failed -- Looking for opterr - not found -- Looking for optreset CMake Error at CMakeLists.txt:10 (ADD_EXECUTABLE): Target "cmTryCompileExec3458204847" links to item " m" which has leading or trailing whitespace. This is now an error according to policy CMP0004. CMake Error: Internal CMake error, TryCompile generation of cmake failed -- Looking for optreset - not found -- Looking for fseeko CMake Error at CMakeLists.txt:10 (ADD_EXECUTABLE): Target "cmTryCompileExec2628321539" links to item " m" which has leading or trailing whitespace. This is now an error according to policy CMP0004. CMake Error: Internal CMake error, TryCompile generation of cmake failed which I have no idea whether they are an actual problem or just "configure" noise Can you send issue into github? https://github.com/stalkerg/postgres_cmake/issues -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] [GENERAL] C++ port of Postgres
Aleksander Alekseev wrote: You are right, there is none. First: trees in parser, planer and etc. Second: normal exception. Two big projects lately move to C++ from C: GCC, Mesa You can read their reasons. Only C++ we can use without full rewrite currently. (or ObjectC maybe) If we wish fix C limitations. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] [GENERAL] C++ port of Postgres
Jim Nasby wrote: My hope is that existing hackers can agree on a reasonable way forward and guide/assist new folks that are interested in walking that path. I tried this path. https://github.com/stalkerg/postgres_cpp And I fully support this desire. But I'm in the minority. I also like the idea of investigating Rust. I am working on it last few weeks. But it's like seek blocks for new DB. I don't know how we can insert Rust code into Postgres spaghetti. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Bug in WaitForBackgroundWorkerShutdown() [REL9_5_STABLE]
Dmitry Ivanov wrote: Recently I've encountered a strange crash while calling elog(ERROR, "...") after the WaitForBackgroundWorkerShutdown() function. It turns out that _returns_ inside the PG_TRY()..PG_CATCH() block are *highly* undesirable, since they leave PG_exception_stack pointing to a local struct in a dead frame, which is an obvious UB. I've attached a patch which fixes this behavior in the aforementioned function, but there might be more errors like that elsewhere. Forgot some curly braces, my bad. v2 attached. Good catch. But in 9.6 it has been fixed by db0f6cad4884bd4c835156d3a720d9a79dbd63a9 commit. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Michael Paquier wrote: Personally I am allergic to any kind of UIs for development, and I am sure not to be the only one on this list. Andrew Dunstan: We need this to be scriptable, not using a GUI. GUI is strong optional feature. Helpful for some tasks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Michael Paquier wrote: You have not tested with macOS, and so did I. Thanks! I fixed this typo. But for XCode I see more corrections. I will can fix it today or maybe tomorrow. It would be nice to come as well with simpler steps than all this mkdir build, etc stanza. Perhaps with a wrapper of some kind, in perl that may be a good idea, though perl is not a hard requirement in source tarballs, and on Windows/MSVC it is. Only one extra phase (mkdir build). I think it's not so important. For windows and macosx I used cmake GUI it's so easy. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] WIP: About CMake v2
Hello Hackers. I decided to talk about the current state of the project: 1. Merge with 9.6 master. 2. plpython2, plpython3, plperl, pltcl, plsql all work correctly (all tests pass). 3. Works done for all contrib modules. 4. You can use gettext, .po->.mo will have converted by CMake. 5. All test pass under some Linux, FreeBSD, Solaris10 (on Sparc), Windows MSVC 2015. MacOSX I think not big trouble too. 6. Prototype for PGXS (with MSVC support) done. I think is very big progress but I came across one problem. I not have access to many OS and platforms. For each platform need tests and small fixes. I can't develop and give guarantee without it. I think this is very important work which makes it easier further support Postgres but I can not do everything himself. It's physically impossible. I think without community support I can't do significantly more. Current version you can get here: https://github.com/stalkerg/postgres_cmake Thanks! -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Windows 7, Visual Studio 2010: building PgAdmin3
zeray87 wrote: Hello guys, This is my first ever post and here goes my apology for being newbie. I have been able to build PgAdmin3 after several days of hassle on building PgAdmin3 using build-wxmsw.bat. If I remember it right for PgAdminIII needed mingw now. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Proposal: Remove regress-python3-mangle.mk
Tom Lane wrote: Also, I would bet that those tools would not know anything about converting PL language names between 'plpythonu' and 'plpython2u' and 'plpython3u'; so even if we used one of them, we would still need a layer pretty similar to what we have. I do not see this as a problem because we can build Postgres only with one version of Python (2 or 3). Or am I missing something? may be a bit of a kluge For python developer it is really strange... PS I see Postgres philosophy - do not touch what works well, even if it looks terrible. :) -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Proposal: Remove regress-python3-mangle.mk
Noah Misch wrote: Considering we have 2756 lines of Python test SQL and just thirteen lines of sed to mangle them, the current method is scaling nicely. What pitfalls hides this approach? Convert python2 code to python3 it is really bad practice. I may not understand that second sentence. We have multiple buildfarm members verifying the python2 case and multiple members verifying the python3 case. I wrote about special python3 features what not testing today. We testing Python3 as subset of Python2. The PL/Python implementation does not view them as different languages; But it is really different languages. If we do not want to have two different code base, then it is necessary to use than this: https://pythonhosted.org/six/ The license allows us to copy this code into postgres. Or use standart Python tool 2to3: https://docs.python.org/2/library/2to3.html Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Proposal: Remove regress-python3-mangle.mk
Hello. Now we generate tests for plpython3 of plpython2 tests. I think we should write independently 2 test suite. Why is that bad: 1. Differences between python2 and python3 more than can be solved by regexps. And these differences are growing. 2. We must be careful to write tests, so as not to break the converter. And we can not verify the possibility python3. 3. Because we use sed we do not tests for plpython3 under Windows. And I have trouble with CMake too. Yes, we will have 2 times more similar code but you need to relates to the python2 and python3 as the different languages. Thank you for attention. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Justin Clift wrote: Simon included a short starter list of potentials which might be in that category: * SQL compliant identifiers * Remove RULEs * Change recovery.conf * Change block headers * Retire template0, template1 * Optimise FSM * Add heap metapage * Alter tuple headers et al + CMake build I think. Now I can build: * postgres * bin/* programs * pl/* languages * contrib/* (with cmake PGXS analogue) Can run regression and isolation tests for postgres/pl* and all contrib modules. There is still a lot of work but I hope everything will turn out. Also it would be good to get help. Thanks. PS https://github.com/stalkerg/postgres_cmake -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] So, can we stop supporting Windows native now?
Craig Ringer wrote: Yeah, you're right. He's not the only one either. I was reacting to the original post, and TBH didn't think it through. The commit logs suggest there's a decent amount of work that goes in, and I'm sure a lot of it isn't visible when just looking for 'windows', 'win32', 'msvc', etc. Even the build system affects people who don't use it, if they're adding features. I recently backported a bunch of 9.3 functionality to 9.1, and in the process simply stripped out all the Windows build system changes as "meh, too hard, don't care". So yeah. I casually handwaved away a lot of work that's not highly visible, but still happens and is important, and was wrong to do so. I've done a bit on Windows myself but didn't fully recognise the burden support for it places on patches to core infrastructure and on committers. Maybe someone in the community to appoint a chief for Windows? -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] So, can we stop supporting Windows native now?
Craig Ringer wrote: If we eventually get a CMake build system conversion that'll mostly go away too. I'm working on it. But the build system does not solve the problem of some hacks. We must nevertheless spend more time for Windows or at least goes to mingw64 (like ActivePerl). -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
Tom Lane wrote: because it would break applications I still do not agree with this. The app expects that there can be no mistakes and it does not happen. I can not invent a situation when it is breaks. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
Vladimir Sitnikov wrote: Just to be clear: I'm not fond of encoding the answer to the universe into statement name. However, I find that "name convention" a smart invention. I forgot one more decision: add GUC variable. A little fatty for this but not touch the protocol and easy to implement. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
I have a big question. What need to do with message protocol? If we write name in Parse message we store prepared statement. I see some solutions for this problem but all not ideal: 1. We can add second char token for parse message. But too serious change. 2. We can try add parameter to tail of message. But in tail we have variable length array with parameters. 3. Detect prefix of prepared name. For example "__". Effects think clear. I would like to know the community opinion on this matter. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
Michael Meskes wrote: While ecpg may not be the choice for new applications, there are a lot of legacy applications out there that need ecpg to be migrated to PostgreSQL. 2016 is a good time to rewrite them. ;) I think Postgres will be more likely if it would be a little less concerned about compatibility IMHO. But I will not insist. My problem with ecpg I decided. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
Michael Meskes wrote: More than you think. I doubt you want to propose removing features that make developing new features harder, or do you? :) I want to understand the situation. You may want to make the build ecpg optional. Personally, I want to. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
Fabrízio de Royes Mello wrote:
I got an error when build this patch.
I fix it! All tests pass (include ecpg tests).
Patch in attachment.
Thanks.
PS Who use ecpg? For me it's like hell.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/doc/src/sgml/ref/prepare.sgml b/doc/src/sgml/ref/prepare.sgml
index dbce8f2..c52879f 100644
--- a/doc/src/sgml/ref/prepare.sgml
+++ b/doc/src/sgml/ref/prepare.sgml
@@ -26,7 +26,7 @@ PostgreSQL documentation
-PREPARE name [ ( data_type [, ...] ) ] AS statement
+PREPARE [ IF NOT EXISTS ] name [ ( data_type [, ...] ) ] AS statement
@@ -86,6 +86,15 @@ PREPARE name [ (
+IF NOT EXISTS
+
+
+ Do not throw an error if a prepare statement with the same name already exists.
+
+
+
+
+
name
diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index cec37ce..019330f 100644
--- a/src/backend/commands/prepare.c
+++ b/src/backend/commands/prepare.c
@@ -59,6 +59,7 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
int nargs;
Query *query;
List *query_list;
+ bool found;
int i;
/*
@@ -70,6 +71,30 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
(errcode(ERRCODE_INVALID_PSTATEMENT_DEFINITION),
errmsg("invalid statement name: must not be empty")));
+ /* Find entry in hash table */
+ if(prepared_queries)
+ {
+ hash_search(prepared_queries,
+ stmt->name,
+ HASH_FIND,
+ );
+
+ /* Shouldn't get a duplicate entry */
+ if (found && stmt->if_not_exists)
+ {
+ ereport(NOTICE,
+ (errcode(ERRCODE_DUPLICATE_PSTATEMENT),
+ errmsg("prepared statement \"%s\" already exists, skipping",
+ stmt->name)));
+ return;
+ }
+ else if (found && !stmt->if_not_exists)
+ ereport(ERROR,
+ (errcode(ERRCODE_DUPLICATE_PSTATEMENT),
+ errmsg("prepared statement \"%s\" already exists",
+ stmt->name)));
+ }
+
/*
* Create the CachedPlanSource before we do parse analysis, since it needs
* to see the unmodified raw parse tree.
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index df7c2fa..be8ac78 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -4021,6 +4021,7 @@ _copyPrepareStmt(const PrepareStmt *from)
COPY_STRING_FIELD(name);
COPY_NODE_FIELD(argtypes);
COPY_NODE_FIELD(query);
+ COPY_SCALAR_FIELD(if_not_exists);
return newnode;
}
diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c
index b9c3959..fbd248b 100644
--- a/src/backend/nodes/equalfuncs.c
+++ b/src/backend/nodes/equalfuncs.c
@@ -2017,6 +2017,7 @@ _equalPrepareStmt(const PrepareStmt *a, const PrepareStmt *b)
COMPARE_STRING_FIELD(name);
COMPARE_NODE_FIELD(argtypes);
COMPARE_NODE_FIELD(query);
+ COMPARE_SCALAR_FIELD(if_not_exists);
return true;
}
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index b9aeb31..e08d95f 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -9443,6 +9443,16 @@ PrepareStmt: PREPARE name prep_type_clause AS PreparableStmt
n->name = $2;
n->argtypes = $3;
n->query = $5;
+ n->if_not_exists = false;
+ $$ = (Node *) n;
+}
+ | PREPARE IF_P NOT EXISTS name prep_type_clause AS PreparableStmt
+{
+ PrepareStmt *n = makeNode(PrepareStmt);
+ n->name = $5;
+ n->argtypes = $6;
+ n->query = $8;
+ n->if_not_exists = true;
$$ = (Node *) n;
}
;
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index 2fd0629..f08dee4 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -2986,6 +2986,7 @@ typedef struct PrepareStmt
char *name; /* Name of plan, arbitrary */
List *argtypes; /* Types of parameters (List of TypeName) */
Node *query; /* The query itself (as a raw parsetree) */
+ bool if_not_exists;
} PrepareStmt;
diff --git a/src/interfaces/ecpg/preproc/check_rules.pl b/src/interfaces/ecpg/preproc/check_rules.pl
index 4c981e0..cba9a74 100644
--- a/src/interfaces/ecpg/preproc/check_rules.pl
+++ b/src/interfaces/ecpg/preproc/check_rules.pl
@@ -43,7 +43,9 @@ my %replace_line = (
=> 'CREATE OptTemp TABLE create_as_target AS EXECUTE prepared_name execute_param_clause',
'PrepareStmtPREPAREnameprep_type_clauseASPreparableStmt' =>
- 'PREPARE prepared_name prep_type_clause AS PreparableStmt');
+ 'PREPARE prepared_name prep_type_clause AS PreparableStmt',
+ 'PrepareStmtPREPAREIF_PNOTEXISTSnameprep_type_clauseASPreparableStmt' =>
+ 'PREPARE IF_P NOT EXISTS prepared_name prep_type_clause AS PreparableStmt');
my $block= '';
my $yaccmode = 0;
diff --git a/src/interfaces/ecpg/preproc/ecpg.addons b/src/interfaces/ecpg/preproc/ecpg.addons
index b3b36cf..c2742cf 100644
---
Re: [HACKERS] NOT EXIST for PREPARE
Fabrízio de Royes Mello wrote: I got an error when build this patch. Thanks for review and tests! I'm working on it. Without ecpg everything works fine. In ecpg we have black perl magic and special rules for PREPARE. The error is in perl script. Regards -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
Fabrízio de Royes Mello wrote: You're correct. Yury please add your patch to the next commitfest. Done. But I do not have restrictions as part of our PostgresPro distr. I think this patch will be in production a month. Big Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
I was not sure about the syntax, so this was a prototype. Now, like all
completed yet.
1) I think this syntax is wrong... Instead the common should be:
PREPARE [IF NOT EXISTS] ...
You right. Done.
2) All of CINE statements we emit a NOTICE skipping message, so you should
emit a message like it:
Done.
3) There are no regression tests
Done.
4) There are no docs
Done.
Regards.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/doc/src/sgml/ref/prepare.sgml b/doc/src/sgml/ref/prepare.sgml
index dbce8f2..c52879f 100644
--- a/doc/src/sgml/ref/prepare.sgml
+++ b/doc/src/sgml/ref/prepare.sgml
@@ -26,7 +26,7 @@ PostgreSQL documentation
-PREPARE name [ ( data_type [, ...] ) ] AS statement
+PREPARE [ IF NOT EXISTS ] name [ ( data_type [, ...] ) ] AS statement
@@ -86,6 +86,15 @@ PREPARE name [ (
+IF NOT EXISTS
+
+
+ Do not throw an error if a prepare statement with the same name already exists.
+
+
+
+
+
name
diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index cec37ce..019330f 100644
--- a/src/backend/commands/prepare.c
+++ b/src/backend/commands/prepare.c
@@ -59,6 +59,7 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
int nargs;
Query *query;
List *query_list;
+ bool found;
int i;
/*
@@ -70,6 +71,30 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
(errcode(ERRCODE_INVALID_PSTATEMENT_DEFINITION),
errmsg("invalid statement name: must not be empty")));
+ /* Find entry in hash table */
+ if(prepared_queries)
+ {
+ hash_search(prepared_queries,
+ stmt->name,
+ HASH_FIND,
+ );
+
+ /* Shouldn't get a duplicate entry */
+ if (found && stmt->if_not_exists)
+ {
+ ereport(NOTICE,
+ (errcode(ERRCODE_DUPLICATE_PSTATEMENT),
+ errmsg("prepared statement \"%s\" already exists, skipping",
+ stmt->name)));
+ return;
+ }
+ else if (found && !stmt->if_not_exists)
+ ereport(ERROR,
+ (errcode(ERRCODE_DUPLICATE_PSTATEMENT),
+ errmsg("prepared statement \"%s\" already exists",
+ stmt->name)));
+ }
+
/*
* Create the CachedPlanSource before we do parse analysis, since it needs
* to see the unmodified raw parse tree.
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index df7c2fa..be8ac78 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -4021,6 +4021,7 @@ _copyPrepareStmt(const PrepareStmt *from)
COPY_STRING_FIELD(name);
COPY_NODE_FIELD(argtypes);
COPY_NODE_FIELD(query);
+ COPY_SCALAR_FIELD(if_not_exists);
return newnode;
}
diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c
index b9c3959..fbd248b 100644
--- a/src/backend/nodes/equalfuncs.c
+++ b/src/backend/nodes/equalfuncs.c
@@ -2017,6 +2017,7 @@ _equalPrepareStmt(const PrepareStmt *a, const PrepareStmt *b)
COMPARE_STRING_FIELD(name);
COMPARE_NODE_FIELD(argtypes);
COMPARE_NODE_FIELD(query);
+ COMPARE_SCALAR_FIELD(if_not_exists);
return true;
}
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index b9aeb31..e08d95f 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -9443,6 +9443,16 @@ PrepareStmt: PREPARE name prep_type_clause AS PreparableStmt
n->name = $2;
n->argtypes = $3;
n->query = $5;
+ n->if_not_exists = false;
+ $$ = (Node *) n;
+}
+ | PREPARE IF_P NOT EXISTS name prep_type_clause AS PreparableStmt
+{
+ PrepareStmt *n = makeNode(PrepareStmt);
+ n->name = $5;
+ n->argtypes = $6;
+ n->query = $8;
+ n->if_not_exists = true;
$$ = (Node *) n;
}
;
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index 2fd0629..f08dee4 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -2986,6 +2986,7 @@ typedef struct PrepareStmt
char *name; /* Name of plan, arbitrary */
List *argtypes; /* Types of parameters (List of TypeName) */
Node *query; /* The query itself (as a raw parsetree) */
+ bool if_not_exists;
} PrepareStmt;
diff --git a/src/test/regress/expected/prepare.out b/src/test/regress/expected/prepare.out
index 7016e82..e870622 100644
--- a/src/test/regress/expected/prepare.out
+++ b/src/test/regress/expected/prepare.out
@@ -39,6 +39,23 @@ SELECT name, statement, parameter_types FROM pg_prepared_statements;
q2 | PREPARE q2 AS SELECT 2 AS b; | {}
(2 rows)
+-- if not exist
+PREPARE q1 AS SELECT 1 AS a;
+ERROR: prepared statement "q1" already exists
+PREPARE q1 AS SELECT 1 AS a;
+ERROR: prepared statement "q1" already exists
+PREPARE IF NOT EXISTS q1 AS SELECT 1 AS a;
+NOTICE: prepared statement "q1" already exists, skipping
+DEALLOCATE q1;
+PREPARE IF NOT EXISTS
Re: [HACKERS] NOT EXIST for PREPARE
Yury Zhuravlev wrote:
You already have a patch? If yes I'm glad to review it.
Please. Patch in attachment.
Fix bug, forgot change attr number in parser.
And, I forgot example:
PREPARE usrrptplan (int) IF NOT EXISTS AS
SELECT * FROM pg_operator;
PREPARE
New patch in attachment.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index cec37ce..63d164f 100644
--- a/src/backend/commands/prepare.c
+++ b/src/backend/commands/prepare.c
@@ -59,6 +59,7 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
int nargs;
Query *query;
List *query_list;
+ bool found;
int i;
/*
@@ -70,6 +71,24 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
(errcode(ERRCODE_INVALID_PSTATEMENT_DEFINITION),
errmsg("invalid statement name: must not be empty")));
+ /* Find entry in hash table */
+ if(prepared_queries)
+ {
+ hash_search(prepared_queries,
+ stmt->name,
+ HASH_FIND,
+ );
+
+ /* Shouldn't get a duplicate entry */
+ if (found && stmt->if_not_exists)
+ return;
+ else if (found && !stmt->if_not_exists)
+ ereport(ERROR,
+ (errcode(ERRCODE_DUPLICATE_PSTATEMENT),
+ errmsg("prepared statement \"%s\" already exists",
+ stmt->name)));
+ }
+
/*
* Create the CachedPlanSource before we do parse analysis, since it needs
* to see the unmodified raw parse tree.
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index df7c2fa..be8ac78 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -4021,6 +4021,7 @@ _copyPrepareStmt(const PrepareStmt *from)
COPY_STRING_FIELD(name);
COPY_NODE_FIELD(argtypes);
COPY_NODE_FIELD(query);
+ COPY_SCALAR_FIELD(if_not_exists);
return newnode;
}
diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c
index b9c3959..fbd248b 100644
--- a/src/backend/nodes/equalfuncs.c
+++ b/src/backend/nodes/equalfuncs.c
@@ -2017,6 +2017,7 @@ _equalPrepareStmt(const PrepareStmt *a, const PrepareStmt *b)
COMPARE_STRING_FIELD(name);
COMPARE_NODE_FIELD(argtypes);
COMPARE_NODE_FIELD(query);
+ COMPARE_SCALAR_FIELD(if_not_exists);
return true;
}
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index b9aeb31..6eb69e3 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -9443,6 +9443,16 @@ PrepareStmt: PREPARE name prep_type_clause AS PreparableStmt
n->name = $2;
n->argtypes = $3;
n->query = $5;
+ n->if_not_exists = false;
+ $$ = (Node *) n;
+}
+ | PREPARE name prep_type_clause IF_P NOT EXISTS AS PreparableStmt
+{
+ PrepareStmt *n = makeNode(PrepareStmt);
+ n->name = $2;
+ n->argtypes = $3;
+ n->query = $8;
+ n->if_not_exists = true;
$$ = (Node *) n;
}
;
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index 2fd0629..f08dee4 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -2986,6 +2986,7 @@ typedef struct PrepareStmt
char *name; /* Name of plan, arbitrary */
List *argtypes; /* Types of parameters (List of TypeName) */
Node *query; /* The query itself (as a raw parsetree) */
+ bool if_not_exists;
} PrepareStmt;
--
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] NOT EXIST for PREPARE
You already have a patch? If yes I'm glad to review it.
Please. Patch in attachment.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index cec37ce..63d164f 100644
--- a/src/backend/commands/prepare.c
+++ b/src/backend/commands/prepare.c
@@ -59,6 +59,7 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
int nargs;
Query *query;
List *query_list;
+ bool found;
int i;
/*
@@ -70,6 +71,24 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
(errcode(ERRCODE_INVALID_PSTATEMENT_DEFINITION),
errmsg("invalid statement name: must not be empty")));
+ /* Find entry in hash table */
+ if(prepared_queries)
+ {
+ hash_search(prepared_queries,
+ stmt->name,
+ HASH_FIND,
+ );
+
+ /* Shouldn't get a duplicate entry */
+ if (found && stmt->if_not_exists)
+ return;
+ else if (found && !stmt->if_not_exists)
+ ereport(ERROR,
+ (errcode(ERRCODE_DUPLICATE_PSTATEMENT),
+ errmsg("prepared statement \"%s\" already exists",
+ stmt->name)));
+ }
+
/*
* Create the CachedPlanSource before we do parse analysis, since it needs
* to see the unmodified raw parse tree.
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index df7c2fa..be8ac78 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -4021,6 +4021,7 @@ _copyPrepareStmt(const PrepareStmt *from)
COPY_STRING_FIELD(name);
COPY_NODE_FIELD(argtypes);
COPY_NODE_FIELD(query);
+ COPY_SCALAR_FIELD(if_not_exists);
return newnode;
}
diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c
index b9c3959..fbd248b 100644
--- a/src/backend/nodes/equalfuncs.c
+++ b/src/backend/nodes/equalfuncs.c
@@ -2017,6 +2017,7 @@ _equalPrepareStmt(const PrepareStmt *a, const PrepareStmt *b)
COMPARE_STRING_FIELD(name);
COMPARE_NODE_FIELD(argtypes);
COMPARE_NODE_FIELD(query);
+ COMPARE_SCALAR_FIELD(if_not_exists);
return true;
}
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index b9aeb31..7449f82 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -9443,6 +9443,16 @@ PrepareStmt: PREPARE name prep_type_clause AS PreparableStmt
n->name = $2;
n->argtypes = $3;
n->query = $5;
+ n->if_not_exists = false;
+ $$ = (Node *) n;
+}
+ | PREPARE name prep_type_clause IF_P NOT EXISTS AS PreparableStmt
+{
+ PrepareStmt *n = makeNode(PrepareStmt);
+ n->name = $2;
+ n->argtypes = $3;
+ n->query = $5;
+ n->if_not_exists = true;
$$ = (Node *) n;
}
;
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index 2fd0629..f08dee4 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -2986,6 +2986,7 @@ typedef struct PrepareStmt
char *name; /* Name of plan, arbitrary */
List *argtypes; /* Types of parameters (List of TypeName) */
Node *query; /* The query itself (as a raw parsetree) */
+ bool if_not_exists;
} PrepareStmt;
--
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] NOT EXIST for PREPARE
Fabrízio de Royes Mello wrote: Skip error if already exists when catched in src/backend/commands/prepare.c isn't enough? I think that's enough. And expand PrepareStmt of course. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
Yury Zhuravlev wrote: It may be necessary to add an index on the field "statement"? Sorry. Said nonsense. We need to understand what kind of behavior should be if the name is the same but query_string not? Replace? Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
Fabrízio de Royes Mello wrote: You already have a patch? If yes I'm glad to review it. If the community is not against it, I'll do it quickly. Changing the syntax is the risk. In addition, we have already missed 9.6. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
Andres Freund wrote: you'd still need to compare the statement somehow You right, I think about that as syntax sugar. Maybe with some performance increase but hardly. We can save on a round trip. It may be necessary to add an index on the field "statement"? Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] NOT EXIST for PREPARE
Fabrízio de Royes Mello wrote: I think you meant IF NOT EXISTS, right? Thanks, you right. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] NOT EXIST for PREPARE
Hello hackers. Do I understand correctly the only way know availability PREPARE it will appeal to pg_prepared_statements? I think this is not a good practice. In some cases, we may not be aware of the PREPARE made (pgpool). Moreover, it seems popular question in the Internet: http://stackoverflow.com/questions/1193020/php-postgresql-check-if-a-prepared-statement-already-exists What do you think about adding NOT EXIST functionality to PREPARE? Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] flex: where's THIS been all this time?
While I'm not quite sufficiently excited to run around and fix all our .l files like this today, I'm definitely planning to do it for psql's lexer, since I'm messing with that right now, and I don't much like Horiguchi-san's solution to the problem. +1. More less code for CMake. PS This hack gives a slight inconvenience. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] GinPageIs* don't actually return a boolean
Robert Haas wrote:
On Wed, Mar 2, 2016 at 9:48 PM, Peter Eisentraut <pete...@gmx.net> wrote:
On 2/11/16 9:30 PM, Michael Paquier wrote: ...
We need to decide what to do about this. I disagree with Peter: I
think that regardless of stdbool, what we've got right now is sloppy
coding - bad style if nothing else. Furthermore, I think that while C
lets you use any non-zero value to represent true, our bool type is
supposed to contain only one of those two values. Therefore, I think
we should commit the full patch, back-patch it as far as somebody has
the energy for, and move on. But regardless, this patch can't keep
sitting in the CommitFest - we either have to take it or reject it,
and soon.
I know that we are trying to do the right thing. But right now there is an
error only in ginStepRight. Maybe now the fix this place, and we will think
about "bool" then? The patch is attached (small and simple).
Thanks.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/backend/access/gin/ginbtree.c b/src/backend/access/gin/ginbtree.c
index 06ba9cb..30113d0 100644
--- a/src/backend/access/gin/ginbtree.c
+++ b/src/backend/access/gin/ginbtree.c
@@ -162,8 +162,8 @@ ginStepRight(Buffer buffer, Relation index, int lockmode)
{
Buffer nextbuffer;
Pagepage = BufferGetPage(buffer);
- boolisLeaf = GinPageIsLeaf(page);
- boolisData = GinPageIsData(page);
+ uint8 isLeaf = GinPageIsLeaf(page);
+ uint8 isData = GinPageIsData(page);
BlockNumber blkno = GinPageGetOpaque(page)->rightlink;
nextbuffer = ReadBuffer(index, blkno);
--
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] GinPageIs* don't actually return a boolean
Michael Paquier wrote: FWIW, when compiling with MS 2015 using the set of perl scripts I am not seeing this compilation error... This error not in build stage but in GIN regresion tests. CMake nothing to do with. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] GinPageIs* don't actually return a boolean
Andres Freund wrote: I plan to commit something like this, unless there's very loud protest from Peter's side. I agree. Peter proposal can be considered in a separate thread. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] VS 2015 support in src/tools/msvc
Good point. It did not occur to me that this would bring a hard dependency for non-Windows builds. Let's keep both scripts then. The attached is changed to do so. Hello. What about putenv problem? We can't write: #define putenv(x) pgwin32_putenv(x) because in new CRT putenv have different signature. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] [PATH] Correct negative/zero year in to_date/to_timestamp
But I'm waiting for a discussion: what part should be changed? I for compliance with the standard (all ISO). In addition Oracle uses "IYYY" format. Standards allow to reduce liability. But I think someone like Tom Lane can have the final say because we break backward compatibility. Options "year"/"isoyear" may confuse the users. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] proposal: get oldest LSN - function
Hello. You forgot to declare a GetXLogOldestLSNPtr function in a header file (in xlog.h I think). Some compilers refuse to compile this code (MSVC for example). Now I see warning from GCC: xlog.c:10627:1: warning: no previous prototype for «GetXLogOldestLSNPtr» [-Wmissing-prototypes] GetXLogOldestLSNPtr(void) Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] PostgreSQL extension API? Documentation?
Álvaro Hernández Tortosa wrote: I wouldn't mind volunteering for this work, but I guess I would need some help to understand and identify the candidate parts of the API. If anyone could help me here, please let me know. When you write an extension often regret that someone specified this or that function as static. I am not sure that such a list ever be complete. In Postgres no clear boundaries between the subsystems. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator
Roma Sokolov wrote: See v2 of the patch attached. Hello. I have a stylistic comments. Sometimes you forget a space: + replaces[Anum_pg_operator_oprcom - 1] =true; or use tab insted space: + if (OidIsValid(op->oprnegate) || + (OidIsValid(op->oprcom) && operOid != op->oprcom)) + OperatorUpd(operOid, + operOid == op->oprcom ? InvalidOid : op->oprcom, + op->oprnegate, + true); And I think if you make this logic into a separate function, it is possible to simplify the code. OperatorUpd function is too complex. Also better to add comments to the tests. The rest seems good. PS I here thought it would be possible to print operators that have been changed? -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Crash with old Windows on new CPU
Tom Lane wrote: Lastly, I'd like to see some discussion of what side effects "_set_FMA3_enable(0);" has ... I rather doubt that it's really a magic-elixir-against-crashes-with-no-downsides. That would give us some context to estimate the risks of this code executing when it's not really needed. Without that, I'd be worried that this cure is worse than the disease because it breaks cases that weren't broken befor I think I have already proposed to drop MSVC support? :) Too many problems due to of one compiler... PS Cry from the heart. I work too much with him. Never mind. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] GinPageIs* don't actually return a boolean
Yury Zhuravlev wrote: Robert Haas wrote: So, is it being pulled in indirectly by some other #include? I can double-check it tomorrow. I've found who include stdbool.h and think it is inevitable for MSVC2013 and MSVC2015. In port/win32.h we inlcude process.h. In process.h included corecrt_startup.h. In corecrt_startup.h included vcruntime_startup.h. In vcruntime_startup.h we included stdbool.h tadam! -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] GinPageIs* don't actually return a boolean
Andres Freund wrote: Did you read what I wrote? Read. That's not correct for char booleans, because the can have different bits set. Current code support this behavior. But to shoot his leg becomes easier. != 0 much better of course. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] GinPageIs* don't actually return a boolean
Andres Freund wrote: Unless I am missing something major, that doesn't seem to achieve all that much. A cast to a char based bool wouldn't normalize this to 0 or 1. So you're still not guaranteed to be able to do somebool == anotherbool when either are set based on such a macro. In C99 cast to bool return 0 or 1 only. In older compilers nothing changes (Now the code is designed to "char == char"). I think this is a good option. But of course to write bool and use char strange. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] GinPageIs* don't actually return a boolean
Robert Haas wrote: So, is it being pulled in indirectly by some other #include? I can double-check it tomorrow. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] GinPageIs* don't actually return a boolean
On вторник, 29 сентября 2015 г. 19:02:59 MSK, Alvaro Herrera wrote: Andres Freund wrote: I went through all headers in src/include and checked for macros containing [^&]&[^&] and checked whether they have this hazard. Found a fair number. That patch also changes !! tests into != 0 style. I don't think you pushed this, did you? Hello hackers! I've just run into a problem with these macro. Function ginStepRight breaks completely when compiled using the MSVC2013 and MSVC2015 (since these releases use C99's bools but without stdbool.h like C++). I don't understand why the patch has not been commited yet. It seems to me not so important !! or ! = 0, the solution is all that matters. Thanks! -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Proposal:Use PGDLLEXPORT for libpq
Michael Paquier wrote: Well, 2015 is not making things easy visibly by not providing direct ways to get locale information. pgwin32_putenv broken too... -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Proposal:Use PGDLLEXPORT for libpq
Michael Paquier wrote: Many companies use it, including mine, and likely EDB. Ok, why? I wonder why it is? -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Proposal:Use PGDLLEXPORT for libpq
So even if the main packages switched to compiling with mingw, we'd probably still want to support MSVC. MinGV more accessible. We can always say that after the release of X is not supported by the MSVC. I do not propose to abandon the MSVC but its use to be justified. Are we moving forward with the CMake stuff? It would be *awesome* to get rid of the MSVC build scripts, and perhaps we can move forward on some smaller items such as PGDLLEXPORT markings as well. Linux build done with installcheck tests. We testing this under CentOS7, Debian8, Gentoo, Ubuntu. MSVC build 50% done. Yesterday made the work of the gendef.pl under CMake. Current issues: https://github.com/stalkerg/postgres_cmake/issues -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Proposal:Use PGDLLEXPORT for libpq
Craig Ringer wrote: Yeah, strongly agree there. CMake has excellent MSVC support btw. Yes... but I found only hack way for call gendef.pl in pre_link stage (get objects folder name). CMake suggests that we use for normal MSVC ways to create dll. OTOH MinGW relies on reverse-engineered headers, an old gcc fork, and has had some pretty nasty bugs. You about MinGW or MinGW64? -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Proposal:Use PGDLLEXPORT for libpq
Craig Ringer wrote: I strongly disagree. MSVC is a high quality compiler and the primary tool for the platform. Ok. And we not suport MSVC2015 now. Either we support the platform normally or throwing it. Now it all looks like a zombie. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Proposal:Use PGDLLEXPORT for libpq
Craig Ringer wrote: On 27 January 2016 at 00:16, Yury Zhuravlev <u.zhurav...@postgrespro.ru> wrote: It says more about the modules, and not about libpq. Using gendef.pl for this library in the light of the development of my CMake build seems silly. For what it's worth I personally agree. I'd rather have PGDLLEXPORT used directly, not least because it'd let us built with -fvisibility=hidden under *nix. But I'm in the minority and not inclined to push the point. If so many problems with MSVC can discard his support of Postgres? MSVC: Not supported C99-C1x. Problems build dynamic library. Realy problems build out-tree module. etc Under windows we can use MinGW64/Msys or LLVM/Clang for MSVC. The current situation is similar to masochism. We're not trying to change the code to make it more portable. But at the same time try using black magic to make Postgres work on non-POSIX systems. What's the point now support the MSVC? Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Proposal:Use PGDLLEXPORT for libpq
Hello hackers. Why we do not use PGDLLEXPORT (__declspec (dllexport)) for the libpq (and other dlls)? Now we are using black magic with gendef.pl for get def (aka export.txt) from .obj files. I have set for some functions and it works. Perhaps there is a circumstance that I do not know but my version seems to me simplify build under Windows. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Proposal:Use PGDLLEXPORT for libpq
Craig Ringer wrote: TL;DR: PGDLLEXPORT is considered ugly Windows-droppings in the code and so a less visible, albeit more convoluted, solution is used. It says more about the modules, and not about libpq. Using gendef.pl for this library in the light of the development of my CMake build seems silly. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Some questions about the array.
I've committed this with a number of revisions, mostly but not entirely cosmetic. Thanks Tom! I feel I still have a lot to learn Postgres to choose the right solution. Your comments are very valuable. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Some questions about the array.
I think you are confused about the difference between a NULL constant (which would give rise to an A_Const syntax tree node) and a NULL syntax tree pointer (which cannot arise from any actual syntactical construct, and would only be present if the grammar put it there due to lack of any corresponding item in the input). regards, tom lane You're right. I will try to provide a patch as soon as possible. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Possible marginally-incompatible change to array subscripting
This would make no difference of course for the common case where the array lower bound is 1, but it seems a lot less arbitrary when it isn't. So I think we should strongly consider changing it to mean that, even though it would be non-backwards-compatible in such cases. Comments? If you break backwards compatibility, it can be done arrays similar to C/C++/Python/Ruby and other languages style? I'm sorry to bring up this thread again... ISTM that if we'd had Yury's code in there from the beginning, what we would define this as meaning is "a[3:4][:5]", ie the implied range runs from whatever the array lower bound is up to the specified subscript. [3:4][:5] instead a[3:4][5] at least this is logical. But after what will result from a[3:4][5]? One element? Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres 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] Some questions about the array.
New patch version in attachment.
Thanks.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/doc/src/sgml/array.sgml b/doc/src/sgml/array.sgml
index 4385a09..305cabb 100644
--- a/doc/src/sgml/array.sgml
+++ b/doc/src/sgml/array.sgml
@@ -257,6 +257,26 @@ SELECT schedule[1:2][1:1] FROM sal_emp WHERE name = 'Bill';
(1 row)
+ It is possible to omit lower-bound or
+ upper-bound
+ of slice operator, since the missing bound will default to the index of the corresponding item.
+
+
+SELECT schedule[:][:] FROM sal_emp WHERE name = 'Bill';
+
+schedule
+
+ {{meeting,lunch},{training,presentation}}
+(1 row)
+
+SELECT schedule[:2][2:] FROM sal_emp WHERE name = 'Bill';
+
+schedule
+
+ {{lunch},{presentation}}
+(1 row)
+
+
If any dimension is written as a slice, i.e., contains a colon, then all
dimensions are treated as slices. Any dimension that has only a single
number (no colon) is treated as being from 1
diff --git a/src/backend/executor/execQual.c b/src/backend/executor/execQual.c
index 29f058c..f586d57 100644
--- a/src/backend/executor/execQual.c
+++ b/src/backend/executor/execQual.c
@@ -268,10 +268,12 @@ ExecEvalArrayRef(ArrayRefExprState *astate,
bool eisnull;
ListCell *l;
int i = 0,
-j = 0;
+j = 0,
+indexexpr;
IntArray upper,
lower;
int *lIndex;
+ AnyArrayType *arrays;
array_source = ExecEvalExpr(astate->refexpr,
econtext,
@@ -293,6 +295,7 @@ ExecEvalArrayRef(ArrayRefExprState *astate,
foreach(l, astate->refupperindexpr)
{
ExprState *eltstate = (ExprState *) lfirst(l);
+ eisnull = false;
if (i >= MAXDIM)
ereport(ERROR,
@@ -300,10 +303,29 @@ ExecEvalArrayRef(ArrayRefExprState *astate,
errmsg("number of array dimensions (%d) exceeds the maximum allowed (%d)",
i + 1, MAXDIM)));
- upper.indx[i++] = DatumGetInt32(ExecEvalExpr(eltstate,
- econtext,
- ,
- NULL));
+ if (eltstate == NULL)
+ {
+ if (isAssignment)
+ereport(ERROR,
+ (errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR),
+ errmsg("cannot determine upper index for empty array")));
+
+ if (astate->refattrlength > 0)
+ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("slices of fixed-length arrays not implemented")));
+
+ arrays = (AnyArrayType *)DatumGetArrayTypeP(array_source);
+ indexexpr = AARR_LBOUND(arrays)[i] + AARR_DIMS(arrays)[i] - 1;
+ }
+ else
+ indexexpr = DatumGetInt32(ExecEvalExpr(eltstate,
+ econtext,
+ ,
+ NULL));
+
+ upper.indx[i++] = indexexpr;
+
/* If any index expr yields NULL, result is NULL or error */
if (eisnull)
{
@@ -321,6 +343,7 @@ ExecEvalArrayRef(ArrayRefExprState *astate,
foreach(l, astate->reflowerindexpr)
{
ExprState *eltstate = (ExprState *) lfirst(l);
+ eisnull = false;
if (j >= MAXDIM)
ereport(ERROR,
@@ -328,10 +351,19 @@ ExecEvalArrayRef(ArrayRefExprState *astate,
errmsg("number of array dimensions (%d) exceeds the maximum allowed (%d)",
j + 1, MAXDIM)));
- lower.indx[j++] = DatumGetInt32(ExecEvalExpr(eltstate,
- econtext,
- ,
- NULL));
+ if (eltstate == NULL)
+ {
+arrays = (AnyArrayType *)DatumGetArrayTypeP(array_source);
+indexexpr = AARR_LBOUND(arrays)[j];
+ }
+ else
+indexexpr = DatumGetInt32(ExecEvalExpr(eltstate,
+ econtext,
+ ,
+ NULL));
+
+ lower.indx[j++] = indexexpr;
+
/* If any index expr yields NULL, result is NULL or error */
if (eisnull)
{
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index 26264cb..fe848d5 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -2417,6 +2417,7 @@ _copyAIndices(const A_Indices *from)
COPY_NODE_FIELD(lidx);
COPY_NODE_FIELD(uidx);
+ COPY_SCALAR_FIELD(is_slice);
return newnode;
}
diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c
index aa6e102..00f98ef 100644
--- a/src/backend/nodes/equalfuncs.c
+++ b/src/backend/nodes/equalfuncs.c
@@ -2162,6 +2162,7 @@ _equalAIndices(const A_Indices *a, const A_Indices *b)
{
COMPARE_NODE_FIELD(lidx);
COMPARE_NODE_FIELD(uidx);
+ COMPARE_SCALAR_FIELD(is_slice);
return true;
}
diff --git a/src/backend/nodes/outfuncs.c b/src/backend/nodes/outfuncs.c
index 012c14b..5c6326d 100644
--- a/src/backend/nodes/outfuncs.c
+++ b/src/backend/nodes/outfuncs.c
@@ -2773,6 +2773,7 @@ _outA_Indices(StringInfo str, const A_Indices *node)
WRITE_NODE_FIELD(lidx);
WRITE_NODE_FIELD(uidx);
+ WRITE_BOOL_FIELD(is_slice);
}
static void
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 7916df8..4afc572 100644
--- a/src/backend/parser/gram.y
+++ b/src/
