[HACKERS] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
On Thu, 2011-02-17 at 00:53 +, Tom Lane wrote: Doesn't anybody around here pay attention to compiler warnings? If you see one, then I accept one was there. I didn't see one, and a full make distclean and re-compile doesn't show a compiler warning for that either. So I guess I'm doing something wrong, on this platform: I'm using Ubuntu 10.04 LTS, with commands for development: ./configure --enable-cassert --enable-depend --enable-debug make -j4 The compile output has been somewhat dirty of late, with various messages, which if nothing else indicated to me that fairly strict warnings were enabled... though I guess not. In file included from gram.y:12758: scan.c: In function ‘yy_try_NUL_trans’: scan.c:16256: warning: unused variable ‘yyg’ elog.c: In function ‘write_console’: elog.c:1702: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result elog.c: In function ‘write_pipe_chunks’: elog.c:2395: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result elog.c:2404: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result common.c: In function ‘handle_sigint’: common.c:247: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result common.c:250: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result common.c:251: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and 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] Fix corner case for binary upgrade: extension functions in pg_catalog.
Tom Lane t...@sss.pgh.pa.us writes: Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane p...@gwene.org writes: Fix corner case for binary upgrade: extension functions in pg_catalog. Do we only want to care about functions here? Yes. Functions/aggregates are the only object type where pg_dump tries to suppress fetching any information at all about system-owned objects; it's the only case where there's so many system objects as to be worth the trouble. Makes for a nice localised fix. Thanks for explaining (again) :) 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] Usability tweaks for extension commands
Tom Lane t...@sss.pgh.pa.us writes: I'm just wondering whether applying that theory is leading to the right choices here. In particular, the default behavior if you didn't say SCHEMA something would be to automatically move the extension into whatever random schema happens to be the front of your search_path, which might well not be what you intended. Maybe it would be safer to not do a move on the basis of a defaulted schema selection. Now that you say that my vote goes for ERRORing out as soon as both schema and version are not explicitly given. Anyway, I think this is all 9.2 material. I brought it up when I was wondering if there were a chance of making CREATE LANGUAGE translate into a CREATE EXTENSION operation for 9.1. I've since given that up, after realizing that we are nowhere near the point where we'd be able to allow non-superusers to execute CREATE EXTENSION. The permissions and security implications are too complicated to rush through. I know I did not take any time to think about non-superusers and relative security issues in my patches, but somehow though you had some magic bullet here. Baring that, agreed, it's not something to rush in. What I think we could do to solve this particular issue in 9.1 would be for CREATE LANGUAGE to internally create an extension of the same name and with server_version as the version. Long term, we will want to still have a compatibility support for CREATE LANGUAGE to still work, so I think that's a good option here. The version bit, you probably will say something against. Then we could make it '0.' || server_version (so '0.9.1' in fact). And we solve it fully in 9.2 where plpgsql is upgraded to '1.0'. Unless core extensions have the same version as the core product, unlike contrib extensions? So in 9.1 there would be the oddity that to create the plpgsql extension you have to issue CREATE LANGUAGE. But as a result you can set your own extension's control file to require plpgsql. 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] btree_gist (was: CommitFest progress - or lack thereof)
We need to fix inet support as Tom complained and then will commit. Oleg On Wed, 16 Feb 2011, Robert Haas wrote: On Sat, Feb 12, 2011 at 8:19 AM, Robert Haas robertmh...@gmail.com wrote: On Sat, Feb 12, 2011 at 7:47 AM, Stephen Frost sfr...@snowman.net wrote: Oleg, * Oleg Bartunov (o...@sai.msu.su) wrote: what do you need for documentation ? From users point of view we add just knn support and all examples are available in btree_gist.sql and sql subdirectory. Contact me directly, if you have questions. It sure seems like http://www.postgresql.org/docs/9.0/static/btree-gist.html could be and should be improved, in general.. If this module is really still just a test bed for GiST, then perhaps it's not a big deal.. I agree that the documentation there could be a lot better, but I don't think that's a commit-blocker for this patch. However, us reaching beta will be a commit-blocker. Teodor, are you intending to commit this? If so, it needs to be soon. Regards, Oleg _ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: o...@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83 -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
Something like this, Everything must be done on call, due to polymorphic signatures, this can be kept in short living cache, but bear in mind user can alter procedure in meantime. When JDBC driver will detect if procedure call statement is created. 1. Determine procedure oid - how? procedures may have not qualified name. Is any function on backend that will deal with schema search path? You may need to pass procedure parameters or at least types? or we need to mirror backend code to Java? 2. Download procedure signature and parse, determine what is input and what is output. 3. Determine how many output parameters user registered, if 1st parameter is ? = exec(?, ?) 4. If only 1 parameter is output (and its UDT, pure UDT due to relkind) use SELECT (RESULT) as your_param_name FROM f(params) AS RESULT, if I remember well using () puts all in on record Above will resolve some other problems in JDBC. Ad 3. Problem is with 1st parameter, actually result of such procedure may be record, so I think I should get in our address example, when call ? = ench(addres ?), result set like address, address But this is to discussion. Postgresql has own roads, far away from support of any standard. On Thu, 17 Feb 2011 13:14:46 +1300, Oliver Jowett wrote: On 17/02/11 04:23, Tom Lane wrote: Florian Pflug f...@phlo.org writes: Hm, I've browsed through the code and it seems that the current behaviour was implemented on purpose. Yes, it's 100% intentional. The idea is to allow function authors to use OUT-parameter notation (in particular, the convention of assigning to a named variable to set the result) without forcing them into the overhead of returning a record when all they want is to return a scalar. So a single OUT parameter is *supposed* to work just like a function that does returns whatever without any OUT parameters. Even if you think this was a bad choice, which I don't, it's far too late to change it. Any suggestions about how the JDBC driver can express the query to get the behavior that it wants? Specifically, the driver wants to call a particular function with N OUT or INOUT parameters (and maybe some other IN parameters too) and get a resultset with N columns back. The current approach is to say SELECT * FROM f(params) AS RESULT which works in all cases *except* for the case where there is exactly one OUT parameter and it has a record/UDT type. Oliver -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On Feb17, 2011, at 01:14 , Oliver Jowett wrote: Any suggestions about how the JDBC driver can express the query to get the behavior that it wants? Specifically, the driver wants to call a particular function with N OUT or INOUT parameters (and maybe some other IN parameters too) and get a resultset with N columns back. There's no sane way to do that, I fear. You could of course look up the function definition in the catalog before actually calling it, but with overloading and polymorphic types finding the right pg_proc entry seems awfully complex. Your best option is probably to just document this caveat... best regards, Florian Pflug -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On Feb17, 2011, at 10:30 , rsmogura wrote: When JDBC driver will detect if procedure call statement is created. 1. Determine procedure oid - how? procedures may have not qualified name. Is any function on backend that will deal with schema search path? You may need to pass procedure parameters or at least types? or we need to mirror backend code to Java? That change of getting this correct without help from the backend is exactly zero. (Hint: You need to consider overloaded functions and implicit casts of parameters...) best regards, Florian Pflug -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
2011/2/17 Florian Pflug f...@phlo.org: On Feb17, 2011, at 10:30 , rsmogura wrote: When JDBC driver will detect if procedure call statement is created. 1. Determine procedure oid - how? procedures may have not qualified name. Is any function on backend that will deal with schema search path? You may need to pass procedure parameters or at least types? or we need to mirror backend code to Java? That change of getting this correct without help from the backend is exactly zero. (Hint: You need to consider overloaded functions and implicit casts of parameters...) There is only one way - implementation of CALL statement. Any emulation on JDBC level is just way to hell. Now, we have to say - PostgreSQL doesn't support a CALL statement, support only functions - and everybody has to use a different pattern than in other databases. Any emulation on JDBC means, it will be slowly, it will be unpredictable. Regards Pavel Stehule best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] Debian readline/libedit breakage
On 02/10/2011 11:34 PM, Joshua D. Drake wrote: Hello, Per: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 It seems we may have a problem to consider. As far as I know, we are the only major platform that supports libedit but our default is readline. Unfortunately readline is not compatible with OpenSSL (apparently?) licensing. This seems that it may be a problem for us considering the pre-package builds we do. What does everyone think? Should we work on getting libedit up to snuff? JD on lwn.net there's a nice summary about this debate you can read it at (*): http://lwn.net/SubscriberLink/428111/36b6b26832f4309d/ Andrea -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
Yes new node should be created and added for 8.x and 9.x releases... On Thu, 17 Feb 2011 10:53:19 +0100, Pavel Stehule wrote: 2011/2/17 Florian Pflug f...@phlo.org: On Feb17, 2011, at 10:30 , rsmogura wrote: When JDBC driver will detect if procedure call statement is created. 1. Determine procedure oid - how? procedures may have not qualified name. Is any function on backend that will deal with schema search path? You may need to pass procedure parameters or at least types? or we need to mirror backend code to Java? That change of getting this correct without help from the backend is exactly zero. (Hint: You need to consider overloaded functions and implicit casts of parameters...) There is only one way - implementation of CALL statement. Any emulation on JDBC level is just way to hell. Now, we have to say - PostgreSQL doesn't support a CALL statement, support only functions - and everybody has to use a different pattern than in other databases. Any emulation on JDBC means, it will be slowly, it will be unpredictable. Regards Pavel Stehule best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
Lukas Eder wrote: The result set meta data correctly state that there are 6 OUT columns. But only the first 2 are actually fetched (because of a nested UDT)... The data mangling was just a plpgsql syntactic issue, wasn't it? Oliver -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
Maybe change in backend to treat complex types marked in relation as COMPLEX in same way as scalar values is solution, actually I don't know. This can be determined by GUC variable so every one can be happy :) On Thu, 17 Feb 2011 23:08:13 +1300, Oliver Jowett wrote: Lukas Eder wrote: The result set meta data correctly state that there are 6 OUT columns. But only the first 2 are actually fetched (because of a nested UDT)... The data mangling was just a plpgsql syntactic issue, wasn't it? Oliver -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
Florian Pflug wrote: On Feb17, 2011, at 01:14 , Oliver Jowett wrote: Any suggestions about how the JDBC driver can express the query to get the behavior that it wants? Specifically, the driver wants to call a particular function with N OUT or INOUT parameters (and maybe some other IN parameters too) and get a resultset with N columns back. There's no sane way to do that, I fear. You could of course look up the function definition in the catalog before actually calling it, but with overloading and polymorphic types finding the right pg_proc entry seems awfully complex. Your best option is probably to just document this caveat... Well, the JDBC driver does know how many OUT parameters there are before execution happens, so it could theoretically do something different for 1 OUT vs. many OUT parameters. The problem is that currently the translation of the JDBC { call } escape happens early on, well before we know which parameters are OUT parameters. Moving that translation later is, at best, tricky, so I was hoping there was one query form that would handle all cases. Oliver -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
2011/2/17 rsmogura rsmog...@softperience.eu: Yes new node should be created and added for 8.x and 9.x releases... what node? Pavel On Thu, 17 Feb 2011 10:53:19 +0100, Pavel Stehule wrote: 2011/2/17 Florian Pflug f...@phlo.org: On Feb17, 2011, at 10:30 , rsmogura wrote: When JDBC driver will detect if procedure call statement is created. 1. Determine procedure oid - how? procedures may have not qualified name. Is any function on backend that will deal with schema search path? You may need to pass procedure parameters or at least types? or we need to mirror backend code to Java? That change of getting this correct without help from the backend is exactly zero. (Hint: You need to consider overloaded functions and implicit casts of parameters...) There is only one way - implementation of CALL statement. Any emulation on JDBC level is just way to hell. Now, we have to say - PostgreSQL doesn't support a CALL statement, support only functions - and everybody has to use a different pattern than in other databases. Any emulation on JDBC means, it will be slowly, it will be unpredictable. Regards Pavel Stehule best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types of those), to prevent programming errors. On Thu, 17 Feb 2011 23:15:07 +1300, Oliver Jowett wrote: Florian Pflug wrote: On Feb17, 2011, at 01:14 , Oliver Jowett wrote: Any suggestions about how the JDBC driver can express the query to get the behavior that it wants? Specifically, the driver wants to call a particular function with N OUT or INOUT parameters (and maybe some other IN parameters too) and get a resultset with N columns back. There's no sane way to do that, I fear. You could of course look up the function definition in the catalog before actually calling it, but with overloading and polymorphic types finding the right pg_proc entry seems awfully complex. Your best option is probably to just document this caveat... Well, the JDBC driver does know how many OUT parameters there are before execution happens, so it could theoretically do something different for 1 OUT vs. many OUT parameters. The problem is that currently the translation of the JDBC { call } escape happens early on, well before we know which parameters are OUT parameters. Moving that translation later is, at best, tricky, so I was hoping there was one query form that would handle all cases. Oliver -- 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] tsearch Parser Hacking
On 16 Feb 2011, at 23:22, David E. Wheeler da...@kineticode.com wrote: On Feb 14, 2011, at 11:44 PM, Oleg Bartunov wrote: IMO, sooner or later we need to trash that code and replace it with something a bit more modification-friendly. We thought about configurable parser, but AFAIR, we didn't get any support for this at that time. What would it take to change the requirement such that *any* SQL function could be a parser, not only C functions? Maybe require that they turn a nested array of tokens? That way I could just write a function in PL/Perl quite easily. I had just the same thought in mind. But so far I systematically substitute _ and a few other characters to ł which doesn't get interpreted as blanks. But more direct control would be appreciated Jesper -- 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] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake j...@commandprompt.com wrote: On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote: Stephen Frost wrote: -- Start of PGP signed section. * Greg Stark (gsst...@mit.edu) wrote: Well for what it's worth we want to support both. At least the project philosophy has been that commercial derivatives are expected and acceptable so things like EDB's products, or Greenplums, or for that matter Pokertracker's all include other proprietary source that of course has restrictive licenses (OpenSSL-type-licensed except even *more* restrictive). This is a bit backwards, I think.. What you're suggesting is that, some day, we might want community/BSD-licensed PG to link against commercially licensed products from EDB for basic functionality (eg: encryption)? I agree that we want to reduce and eliminate, to the extent possible, our dependence on GPL or OpenSSL-type-licensed libraries. It's unfortunate that there isn't a good non-GPL option for libreadline, but I'm not sure what EDB or anyone else would expect the PG community to do regarding that. Should PG remove support for libreadline? Should the PG community make libedit a good BSD-licensed alternative to libreadline? Neither of those really make sense to me. What are our click-installers doing now? Probably readline but does it matter? We distribute the source to the click installers. Actually, we don't. We used to, but we don't at this point. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander mag...@hagander.net wrote: On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake j...@commandprompt.com wrote: On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote: Stephen Frost wrote: -- Start of PGP signed section. * Greg Stark (gsst...@mit.edu) wrote: Well for what it's worth we want to support both. At least the project philosophy has been that commercial derivatives are expected and acceptable so things like EDB's products, or Greenplums, or for that matter Pokertracker's all include other proprietary source that of course has restrictive licenses (OpenSSL-type-licensed except even *more* restrictive). This is a bit backwards, I think.. What you're suggesting is that, some day, we might want community/BSD-licensed PG to link against commercially licensed products from EDB for basic functionality (eg: encryption)? I agree that we want to reduce and eliminate, to the extent possible, our dependence on GPL or OpenSSL-type-licensed libraries. It's unfortunate that there isn't a good non-GPL option for libreadline, but I'm not sure what EDB or anyone else would expect the PG community to do regarding that. Should PG remove support for libreadline? Should the PG community make libedit a good BSD-licensed alternative to libreadline? Neither of those really make sense to me. What are our click-installers doing now? Probably readline but does it matter? We distribute the source to the click installers. Actually, we don't. We used to, but we don't at this point. Depends on your definition of distribute (and what part you are specifically referring to). There's no tarball, but the installer sources are on git.postgresql.org. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On 17/02/11 23:18, rsmogura wrote: Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types of those), to prevent programming errors. And..? Oliver -- 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] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 4:50 AM, Jason Earl je...@notengoamigos.org wrote: This will be a significant advantage for further free software development, and some projects will decide to make software free in order to use these libraries. You've misread this paragraph. Postgres is already free (except for the OpenSSL restrictions). Even by these people's definitions you don't need to use the GPL to be free. -- greg -- 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] btree_gist (was: CommitFest progress - or lack thereof)
2011/2/17 Oleg Bartunov o...@sai.msu.su: We need to fix inet support as Tom complained and then will commit. I think those are two separate issues. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fwd: [JDBC] Weird issues when reading UDT from stored function
On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote: On 17/02/11 23:18, rsmogura wrote: Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types of those), to prevent programming errors. And..? Oliver And it will throw exception when result will income. If you will remove this then you will lose check against programming errors, when number of expected parameters is different that number of actual parameters. Bear in mind that you will get result set of 6 columns, but only 1 is expected. I think you can't determine what should be returned and how to fix result without signature. -- 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] sepgsql contrib module
On Thu, Feb 17, 2011 at 3:56 AM, Kohei Kaigai kohei.kai...@eu.nec.com wrote: The attached patch removes rules to build a policy package for regression test and modifies documentation part to introduce steps to run the test. Committed. Incidentally, on my Ubuntu system: $ find /usr/share/selinux -name '*ake*' /usr/share/selinux/default/include/Makefile /usr/share/selinux/ubuntu/include/Makefile /usr/share/selinux/mls/include/Makefile Not sure which of these would be the right one to use. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 3:39 AM, Stephen Frost sfr...@snowman.net wrote: * Greg Stark (gsst...@mit.edu) wrote: Well for what it's worth we want to support both. At least the project philosophy has been that commercial derivatives are expected and acceptable so things like EDB's products, or Greenplums, or for that matter Pokertracker's all include other proprietary source that of course has restrictive licenses (OpenSSL-type-licensed except even *more* restrictive). This is a bit backwards, I think.. What you're suggesting is that, some day, we might want community/BSD-licensed PG to link against commercially licensed products from EDB for basic functionality (eg: encryption)? No. Firstly we're not talking about linking -- linking is just a technical step and the law is much fuzzier and general than that. When you build a binary it's a derivative work of all the components that went into building that binary whether they were linked in or not. This includes the macros in the header files that were used, the parser code from bison, etc. Secondly I'm not talking about how what software is in the community licensed PG. We have always said in the past that we want Postgres to be usable by other people to embed in their commercially licensed software and that means that the license has to allow not just redistributing Postgres but redistributing it under more restrictive licenses. -- greg -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On 18/02/11 00:37, rsmogura wrote: On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote: On 17/02/11 23:18, rsmogura wrote: Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types of those), to prevent programming errors. And..? Oliver And it will throw exception when result will income. If you will remove this then you will lose check against programming errors, when number of expected parameters is different that number of actual parameters. Bear in mind that you will get result set of 6 columns, but only 1 is expected. I think you can't determine what should be returned and how to fix result without signature. You've completely missed the point. I am not suggesting we change those checks at all. I am suggesting we change how the JDBC driver translates call escapes to queries so that for N OUT parameters, we always get exactly N result columns, without depending on the datatypes of the parameters in any way. Oliver -- 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] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 11:49, Dave Page dp...@pgadmin.org wrote: On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander mag...@hagander.net wrote: On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake j...@commandprompt.com wrote: On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote: Stephen Frost wrote: -- Start of PGP signed section. * Greg Stark (gsst...@mit.edu) wrote: Well for what it's worth we want to support both. At least the project philosophy has been that commercial derivatives are expected and acceptable so things like EDB's products, or Greenplums, or for that matter Pokertracker's all include other proprietary source that of course has restrictive licenses (OpenSSL-type-licensed except even *more* restrictive). This is a bit backwards, I think.. What you're suggesting is that, some day, we might want community/BSD-licensed PG to link against commercially licensed products from EDB for basic functionality (eg: encryption)? I agree that we want to reduce and eliminate, to the extent possible, our dependence on GPL or OpenSSL-type-licensed libraries. It's unfortunate that there isn't a good non-GPL option for libreadline, but I'm not sure what EDB or anyone else would expect the PG community to do regarding that. Should PG remove support for libreadline? Should the PG community make libedit a good BSD-licensed alternative to libreadline? Neither of those really make sense to me. What are our click-installers doing now? Probably readline but does it matter? We distribute the source to the click installers. Actually, we don't. We used to, but we don't at this point. Depends on your definition of distribute (and what part you are specifically referring to). There's no tarball, but the installer sources are on git.postgresql.org. Oh, my bad - they're back. I was referring to our discussion a couple of weeks back (I think), when you said that was too much work :-P My apologies. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 11:45 AM, Magnus Hagander mag...@hagander.net wrote: On Thu, Feb 17, 2011 at 11:49, Dave Page dp...@pgadmin.org wrote: Depends on your definition of distribute (and what part you are specifically referring to). There's no tarball, but the installer sources are on git.postgresql.org. Oh, my bad - they're back. I was referring to our discussion a couple of weeks back (I think), when you said that was too much work :-P For the record, it wasn't keeping the PG installer source code public that was too much work, it was cleaning out some of the unrelated code from other installers. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On Fri, 18 Feb 2011 00:44:07 +1300, Oliver Jowett wrote: On 18/02/11 00:37, rsmogura wrote: On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote: On 17/02/11 23:18, rsmogura wrote: Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types of those), to prevent programming errors. And..? Oliver And it will throw exception when result will income. If you will remove this then you will lose check against programming errors, when number of expected parameters is different that number of actual parameters. Bear in mind that you will get result set of 6 columns, but only 1 is expected. I think you can't determine what should be returned and how to fix result without signature. You've completely missed the point. I am not suggesting we change those checks at all. I am suggesting we change how the JDBC driver translates call escapes to queries so that for N OUT parameters, we always get exactly N result columns, without depending on the datatypes of the parameters in any way. Oliver May You provide example select for this, and check behaviour with below procedure, too. CREATE OR REPLACE FUNCTION p_enhance_address3(OUT address u_address_type, OUT i1 integer) RETURNS record AS $BODY$ BEGIN SELECT t_author.address INTO address FROM t_author WHERE first_name = 'George'; i1 = 12; END; $BODY$ LANGUAGE plpgsql -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On 18/02/11 00:52, rsmogura wrote: On Fri, 18 Feb 2011 00:44:07 +1300, Oliver Jowett wrote: On 18/02/11 00:37, rsmogura wrote: On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote: On 17/02/11 23:18, rsmogura wrote: Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types of those), to prevent programming errors. And..? Oliver And it will throw exception when result will income. If you will remove this then you will lose check against programming errors, when number of expected parameters is different that number of actual parameters. Bear in mind that you will get result set of 6 columns, but only 1 is expected. I think you can't determine what should be returned and how to fix result without signature. You've completely missed the point. I am not suggesting we change those checks at all. I am suggesting we change how the JDBC driver translates call escapes to queries so that for N OUT parameters, we always get exactly N result columns, without depending on the datatypes of the parameters in any way. Oliver May You provide example select for this, and check behaviour with below procedure, too. CREATE OR REPLACE FUNCTION p_enhance_address3(OUT address u_address_type, OUT i1 integer) RETURNS record AS $BODY$ BEGIN SELECT t_author.address INTO address FROM t_author WHERE first_name = 'George'; i1 = 12; END; $BODY$ LANGUAGE plpgsql Oh god I'm going round and round in circles repeating myself! There are two problems. The first problem is a plpgsql problem in that particular function. It's broken regardless of how you call it. Here's how to fix it: testdb=# CREATE FUNCTION p_enhance_address4 (address OUT u_address_type) AS $$ BEGIN address := (SELECT t_author.address FROM t_author WHERE first_name = 'George'); END; $$ LANGUAGE plpgsql; CREATE FUNCTION testdb=# SELECT * FROM p_enhance_address4(); street | zip | city| country | since| code ++---+-++-- (Parliament Hill,77) | NW31A9 | Hampstead | England | 1980-01-01 | (1 row) The second problem is that the JDBC driver always generates calls in the SELECT * FROM ... form, but this does not work correctly for one-OUT-parameter-that-is-a-UDT, as seen in the example immediately above. Here's how to do the call for that particular case: testdb=# SELECT p_enhance_address4(); p_enhance_address4 --- ((Parliament Hill,77),NW31A9,Hampstead,England,1980-01-01,) (1 row) The challenge is that the bare SELECT form doesn't work for multiple OUT parameters, so the driver has to select one form or the other based on the number of OUT parameters. Any questions? (I'm sure there will be questions. Sigh.) Oliver -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On Feb17, 2011, at 11:15 , Oliver Jowett wrote: Florian Pflug wrote: On Feb17, 2011, at 01:14 , Oliver Jowett wrote: Any suggestions about how the JDBC driver can express the query to get the behavior that it wants? Specifically, the driver wants to call a particular function with N OUT or INOUT parameters (and maybe some other IN parameters too) and get a resultset with N columns back. There's no sane way to do that, I fear. You could of course look up the function definition in the catalog before actually calling it, but with overloading and polymorphic types finding the right pg_proc entry seems awfully complex. Your best option is probably to just document this caveat... Well, the JDBC driver does know how many OUT parameters there are before execution happens, so it could theoretically do something different for 1 OUT vs. many OUT parameters. Right, I had forgotten that JDBC must be told about OUT parameter with registerOutputType() The problem is that currently the translation of the JDBC { call } escape happens early on, well before we know which parameters are OUT parameters. Moving that translation later is, at best, tricky, so I was hoping there was one query form that would handle all cases. Hm, now I'm confused. Even leaving the single-OUT-parameter problem aside, the JDBC statement {call f(?,?)} either translates to SELECT * FROM f($1) or SELECT * FROM f($1, $2) depending on whether one of the parameter is OUT. Without knowing the number of output parameters, how do you distinguish these two cases? best regards, Florian Pflug -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
On 18/02/11 01:08, Florian Pflug wrote: Well, the JDBC driver does know how many OUT parameters there are before execution happens, so it could theoretically do something different for 1 OUT vs. many OUT parameters. Right, I had forgotten that JDBC must be told about OUT parameter with registerOutputType() The problem is that currently the translation of the JDBC { call } escape happens early on, well before we know which parameters are OUT parameters. Moving that translation later is, at best, tricky, so I was hoping there was one query form that would handle all cases. Hm, now I'm confused. Even leaving the single-OUT-parameter problem aside, the JDBC statement {call f(?,?)} either translates to SELECT * FROM f($1) or SELECT * FROM f($1, $2) depending on whether one of the parameter is OUT. Without knowing the number of output parameters, how do you distinguish these two cases? Currently it always includes *all* parameters in the call, regardless of the number of OUT parameters (as mentioned, it doesn't even know how many OUT parameters there are at that point). As we discover OUT parameters, we bind void types to them, and the server does the rest of the heavy lifting. Something roughly equivalent to this: testdb=# PREPARE s1(void) AS SELECT * FROM p_enhance_address4($1); -- function has no IN parameters, one OUT parameter PREPARE testdb=# EXECUTE s1(null); street | zip | city| country | since| code ++---+-++-- (Parliament Hill,77) | NW31A9 | Hampstead | England | 1980-01-01 | (1 row) Oliver -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
snip testdb=# CREATE FUNCTION p_enhance_address4 (address OUT u_address_type) AS $$ BEGIN address := (SELECT t_author.address FROM t_author WHERE first_name = 'George'); END; $$ LANGUAGE plpgsql; CREATE FUNCTION testdb=# SELECT * FROM p_enhance_address4(); street | zip | city| country | since | code ++---+-++-- (Parliament Hill,77) | NW31A9 | Hampstead | England | 1980-01-01 | (1 row) The second problem is that the JDBC driver always generates calls in the SELECT * FROM ... form, but this does not work correctly for one-OUT-parameter-that-is-a-UDT, as seen in the example immediately above. Here's how to do the call for that particular case: testdb=# SELECT p_enhance_address4(); p_enhance_address4 --- ((Parliament Hill,77),NW31A9,Hampstead,England,1980-01-01,) (1 row) The challenge is that the bare SELECT form doesn't work for multiple OUT parameters, so the driver has to select one form or the other based on the number of OUT parameters. Any questions? (I'm sure there will be questions. Sigh.) Oliver I don't want to blame or anything similar, any idea is good, as any effort as well, but if user will register one output parameter, but procedure will have two will it be possible to check this? I'm little lost in this nested records. If there will be no such check I suggest to configure this by connection parameter, because in any way UDTs aren't such popular, user should have choice to decide I want better checks, or I need this! Everything is on my side. -- 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 for Index Advisor related hooks
On Wed, Feb 16, 2011 at 6:37 PM, Tom Lane t...@sss.pgh.pa.us wrote: Gurjeet Singh singh.gurj...@gmail.com writes: On Wed, Feb 16, 2011 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote: The only reason you'd need that code is if you were trying to construct a fake Relation structure, which seems unnecessary and undesirable. The planner requires IndexOptInfo, and for the planner to choose the hypothetical index we need to fill in the fwdsortop, revsortop, opfamily and opcintype, and this is the information that IndexAdvisor populates using IndexSupportInitialize() (at least until c0b5fac7 changed the function signature. Yeah, and the set of stuff you need in IndexOptInfo changed again last week; see collations. Direct access to IndexSupportInitialize is even less useful today than it was a week ago. This stuff has changed many times before, and it will change again in the future, and exporting a private function that has an unrelated purpose is not going to insulate you from needing to deal with that. I guess you are right. What would be the best way to build an IndexOptInfo for a plain BTREE index for different data types? Fetch the values you need and stuff 'em in the struct. Don't expect relcache to do it for you. The only reason relcache is involved in the current workflow is that we try to cache the information across queries in order to save on planner startup time ... but I don't think that that concern is nearly as pressing for something like Index Advisor. You'll have enough to do tracking changes in IndexOptInfo, you don't need to have to deal with refactorings inside relcache as well. I also wish to make Index Advisor faster by not having to lookup this info every time a new query comes in and that's why I was trying to use the guts of IndexSupportInitialize() where it does the caching. If Index Advisor went on its own then we'll be implementing caching of opfamily and opcintype etc in the contrib/ code. And I am pretty sure we can't do it any better than what Postgres is currently doing in terms of managing that cache and possibly invalidating it when some relevant DDL happens. Would it be possible to somehow expose that cache managed by LookupOpclassInfo()? I see the comments above it note that it does not handle invalidation since there's no need for it because currently one cannot ALTER an opclass. But I do not wish to be revisiting this problem when that changes. IOW, when ALTER for opclass is implemented, LookupOpclassInfo would be changed to handle invalidation and I wish to leverage that; it might mean change in function signature, but I guess Index Advisor will have to live with that. Thanks, -- gurjeet.singh @ EnterpriseDB - The Enterprise Postgres Company http://www.EnterpriseDB.com singh.gurjeet@{ gmail | yahoo }.com Twitter/Skype: singh_gurjeet Mail sent from my BlackLaptop device
Re: [HACKERS] ALTER EXTENSION UPGRADE, v3
On fre, 2011-02-11 at 14:19 -0500, Tom Lane wrote: But now, let's make it harder. I've found a grave bug in 1.1, which causes the PG backend to segfault. Easy fix, good thing, so now I release 1.2: Unless the bug is such that you have to change the installation script file, there is no reason to bump the version number at all. These version numbers apply to the install SQL script, not the underlying .so. I think this shows that the installation script version number should be independent of the overall package's version number. You just change the installation script version number when it is required that the script be run as part of an upgrade, otherwise you leave it. This is very similar to the version numbers of shared libraries, which also change independently of the overall package. So perhaps installation script version numbers should just be integers starting at 1, period. Otherwise I fear people will try to make the numbers match their package version number, which will either create stupid installation script sequences or stupid package version numbers, like those peculiar fellows who change the shared library version number in accordance with their package version number. This would of course also simplify many other aspects about which version numbers to allow and how to compare them. -- 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 two dashes in extension load files
On tis, 2011-02-15 at 15:32 -0500, Tom Lane wrote: I can't claim close familiarity with Debian's conventions in this matter, but I do know about RPM's, and I'm uneager to duplicate that silliness. Magic conversion of dots to underscores (sometimes), complete inability to determine which part of the package filename is which without external knowledge, etc. FYI, the system in Debian is that '_' separate package name and version, and '_' is not allowed in package name or version. I guess since we want to allow both '_' and '-' in package names, we can't really do that or anything similar. -- 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
On 17 February 2011 08:30, Simon Riggs si...@2ndquadrant.com wrote: In file included from gram.y:12758: scan.c: In function ‘yy_try_NUL_trans’: scan.c:16256: warning: unused variable ‘yyg’ Lots of people have reported that one. It's been around since August of last year, if not earlier. -- Regards, Peter Geoghegan -- 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
On Thu, 2011-02-17 at 14:37 +, Peter Geoghegan wrote: On 17 February 2011 08:30, Simon Riggs si...@2ndquadrant.com wrote: In file included from gram.y:12758: scan.c: In function ‘yy_try_NUL_trans’: scan.c:16256: warning: unused variable ‘yyg’ Lots of people have reported that one. It's been around since August of last year, if not earlier. Yeh. I wasn't reporting it as an error, just showing the absence of a warning for an uninitialized variable in the case shown. What I should have said was: please share any tips for improving error checking. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
On Thu, Feb 17, 2011 at 9:50 AM, Simon Riggs si...@2ndquadrant.com wrote: On Thu, 2011-02-17 at 14:37 +, Peter Geoghegan wrote: On 17 February 2011 08:30, Simon Riggs si...@2ndquadrant.com wrote: In file included from gram.y:12758: scan.c: In function ‘yy_try_NUL_trans’: scan.c:16256: warning: unused variable ‘yyg’ Lots of people have reported that one. It's been around since August of last year, if not earlier. Yeh. I wasn't reporting it as an error, just showing the absence of a warning for an uninitialized variable in the case shown. What I should have said was: please share any tips for improving error checking. On MacOS X and Fedora, I put COPT=-Werror in src/Makefile.custom. (There's a -Wno-error in the rule that compiles scan.c, so it all works.) But I can't do that on my Ubuntu machine because of those stupid warnings about write(). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Simon Riggs si...@2ndquadrant.com writes: On Thu, 2011-02-17 at 00:53 +, Tom Lane wrote: Doesn't anybody around here pay attention to compiler warnings? If you see one, then I accept one was there. I didn't see one, and a full make distclean and re-compile doesn't show a compiler warning for that either. So I guess I'm doing something wrong, on this platform: I'm using Ubuntu 10.04 LTS, with commands for development: ./configure --enable-cassert --enable-depend --enable-debug make -j4 Hmm ... the only plausible reason I can think of for gcc not showing that warning would be building with -O0 (which disables the flow graph computations needed to detect uses of uninitialized values). Your configure command doesn't betray any such thing, but maybe you've got some CFLAGS overrides you're not showing us? I usually find that -O1 is the best compromise setting for development builds. It enables uninitialized-variable warnings but doesn't produce code that's completely unfriendly to gdb. (Sometimes I do recompile a specific file at -O0 if it's making no sense during single-stepping.) The compile output has been somewhat dirty of late, with various messages, which if nothing else indicated to me that fairly strict warnings were enabled... though I guess not. In my builds, the only warning anywhere is the unused variable in gram.y, which is a bison bug that we can't do anything about (except complain to the bison folk, which I've done). It might be worth trying to clean up those warn_unused_result things, if other people are seeing those. 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] btree_gist (was: CommitFest progress - or lack thereof)
Robert Haas robertmh...@gmail.com writes: 2011/2/17 Oleg Bartunov o...@sai.msu.su: We need to fix inet support as Tom complained and then will commit. I think those are two separate issues. Yeah ... also, fixing the inet problem looked to me like it'd probably be a major compatibility break (change in on-disk index contents). Not something to rush into at the end of a development cycle. In any case, I was pointing to that as a reason that btree_gist wasn't ready to be in core. It has nothing to do with KNN-ifying the module. I would like to see that happen before 9.1, else KNN will go out with not very many actual use-cases supported. 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] Debian readline/libedit breakage
Dave Page wrote: On Thu, Feb 17, 2011 at 11:45 AM, Magnus Hagander mag...@hagander.net wrote: On Thu, Feb 17, 2011 at 11:49, Dave Page dp...@pgadmin.org wrote: Depends on your definition of distribute (and what part you are specifically referring to). There's no tarball, but the installer sources are on git.postgresql.org. Oh, my bad - they're back. I was referring to our discussion a couple of weeks back (I think), when you said that was too much work :-P For the record, it wasn't keeping the PG installer source code public that was too much work, it was cleaning out some of the unrelated code from other installers. Well, we are going down a slippery slope if we think the click-through installers are OK to use readline and distribute because we supply the source for the installers --- that then requires anyone using the binaries (or libraries) in those installers to also supply the source code, e.g. GPL. :-( I am not saying they have to, but falling back to the oh we give source code for the click-through installers is not a position we can fall back on without affecting our users. Also, I think part of the problem for Debian is that they distribute readline and Postgres because they are the operating system vendor. I don't think the use the OS library if already present interpretation of the GPL really thought about that case. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Debian readline/libedit breakage
Stephen Frost wrote: -- Start of PGP signed section. * Bruce Momjian (br...@momjian.us) wrote: Joshua D. Drake wrote: Probably readline but does it matter? We distribute the source to the click installers. Well, there is what the community is risking, and there is what the packagers are risking. Ideally we would make the job easier for the packagers too, though we don't have to. I'm really mystified by this. If the source is available for the installers, what's the risk that you're worried about..? For the community or the packagers? I just posted on this. The risk is to people using the packages --- the packages themselves include the source as an option, so they are fine, but everyone using those packages would also be required to distribute source, which is a restriction we have avoided in the past. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Debian readline/libedit breakage
* Bruce Momjian (br...@momjian.us) wrote: Well, we are going down a slippery slope if we think the click-through installers are OK to use readline and distribute because we supply the source for the installers --- that then requires anyone using the binaries (or libraries) in those installers to also supply the source code, e.g. GPL. If they build binaries which include the GPL'd readline, then there's a (potential) issue, sure. I'm not sure what system you're looking at, but readline isn't linked in by libpq today and I can't imagine it ever being linked to it. If they're using the binaries which the community provides, I really don't believe there's any issue. It's possible someone would ask for the source code for that psql binary, but that shouldn't/wouldn't be hard for them to produce for the community psql. If they're building their own binaries of psql which they've modified *and* have linked in with readline, then they've put themselves into a position where FSF or someone could complain. I'd recommend they not do that, so as to avoid the issue. :-( I am not saying they have to, but falling back to the oh we give source code for the click-through installers is not a position we can fall back on without affecting our users. I really don't follow the logic here. Are you suggesting that people take psql and *embed* it into their own binaries? If there's really that much concern over it, presumably the installers could be built w/o readline support. That'd probably be more comfortable for me anyway, since then psql on Windows would behave like every other Windows app. ;) (j/k..) Also, I think part of the problem for Debian is that they distribute readline and Postgres because they are the operating system vendor. I don't think the use the OS library if already present interpretation of the GPL really thought about that case. I don't think this really plays into this whole thing at all, but my understanding is that Debian intentionally doesn't use that clause because it's vague. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
On Thu, 2011-02-17 at 10:09 -0500, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: On Thu, 2011-02-17 at 00:53 +, Tom Lane wrote: Doesn't anybody around here pay attention to compiler warnings? If you see one, then I accept one was there. I didn't see one, and a full make distclean and re-compile doesn't show a compiler warning for that either. So I guess I'm doing something wrong, on this platform: I'm using Ubuntu 10.04 LTS, with commands for development: ./configure --enable-cassert --enable-depend --enable-debug make -j4 Hmm ... the only plausible reason I can think of for gcc not showing that warning would be building with -O0 (which disables the flow graph computations needed to detect uses of uninitialized values). Your configure command doesn't betray any such thing, but maybe you've got some CFLAGS overrides you're not showing us? No, nothing set I usually find that -O1 is the best compromise setting for development builds. It enables uninitialized-variable warnings but doesn't produce code that's completely unfriendly to gdb. (Sometimes I do recompile a specific file at -O0 if it's making no sense during single-stepping.) The compile output has been somewhat dirty of late, with various messages, which if nothing else indicated to me that fairly strict warnings were enabled... though I guess not. In my builds, the only warning anywhere is the unused variable in gram.y, which is a bison bug that we can't do anything about (except complain to the bison folk, which I've done). It might be worth trying to clean up those warn_unused_result things, if other people are seeing those. Thanks, will investigate. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and 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] Debian readline/libedit breakage
* Bruce Momjian (br...@momjian.us) wrote: I just posted on this. The risk is to people using the packages --- the packages themselves include the source as an option, so they are fine, but everyone using those packages would also be required to distribute source, which is a restriction we have avoided in the past. I think you may want to reread the GPL on this. They're not actually required to distribute source *with* the binaries (hell, Debian doesn't..) as long as they are willing to produce it if asked. And that's the source for the binaries which actually depend on the GPL'd code, eg, the community-built psql binary that you're talking about here.. They don't have to provide source for everything on the CD or something (again, Debian has a non-free section also..). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Add support for logging the current role
On Wed, Feb 16, 2011 at 9:52 PM, Stephen Frost sfr...@snowman.net wrote: * Robert Haas (robertmh...@gmail.com) wrote: Ah, so it does. Sounds like you win. Have we a patch implementing the sounds-like-its-agreed change, then? Patch attached, rebased to current master. Ugg, wait a minute. This not only adds %U; it also changes the behavior of %u, which I don't think we've agreed on. Also, emitting 'none' when not SET ROLE has been done is pretty ugly. I'm back to thinking we need to push this out to 9.2 and take more time to think about this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add support for logging the current role
Robert Haas robertmh...@gmail.com writes: Ugg, wait a minute. This not only adds %U; it also changes the behavior of %u, which I don't think we've agreed on. Also, emitting 'none' when not SET ROLE has been done is pretty ugly. I'm back to thinking we need to push this out to 9.2 and take more time to think about this. Yeah, I thought what was supposed to be emitted was the value of current_user, not SQL's weird definition of what SET ROLE means. 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] Add support for logging the current role
* Robert Haas (robertmh...@gmail.com) wrote: Ugg, wait a minute. This not only adds %U; it also changes the behavior of %u, which I don't think we've agreed on. Also, emitting 'none' when not SET ROLE has been done is pretty ugly. I'm back to thinking we need to push this out to 9.2 and take more time to think about this. As I explained in various commit logs and, as I recall, when I first posted about it, the behavior change for %u could only come about when someone used 'SET SESSION AUTHORIZATION', which requires superuser privileges. It makes more sense to me for 'user_name' to be equivilant to 'SESSION USER', but it's really not that big a deal either way. Guess I had foolishly thought that people were alright with it by lack of any comments on it. :( Does anyone else want to chime in on this? I actually came across that problem because the documentation was poor regarding exactly what that column meant. If we actually want it to be the name that the user first used to authenticate to the system with, then let's update the documentation accordingly and we can remove those changes. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Add support for logging the current role
* Tom Lane (t...@sss.pgh.pa.us) wrote: Robert Haas robertmh...@gmail.com writes: Ugg, wait a minute. This not only adds %U; it also changes the behavior of %u, which I don't think we've agreed on. Also, emitting 'none' when not SET ROLE has been done is pretty ugly. I'm back to thinking we need to push this out to 9.2 and take more time to think about this. Yeah, I thought what was supposed to be emitted was the value of current_user, not SQL's weird definition of what SET ROLE means. current_user uses GetUserNameFromId() and goes through the cache lookups to get there. I was using what show_role() returns (which is also what 'show role;' returns). I'd be happy to make it emit an empty string when 'none' is returned though. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] ALTER EXTENSION UPGRADE, v3
Peter Eisentraut pete...@gmx.net writes: On fre, 2011-02-11 at 14:19 -0500, Tom Lane wrote: Unless the bug is such that you have to change the installation script file, there is no reason to bump the version number at all. These version numbers apply to the install SQL script, not the underlying .so. I think this shows that the installation script version number should be independent of the overall package's version number. You just change the installation script version number when it is required that the script be run as part of an upgrade, otherwise you leave it. This is very similar to the version numbers of shared libraries, which also change independently of the overall package. So perhaps installation script version numbers should just be integers starting at 1, period. Well, people are certainly free to use them that way, but I'm not sure there's much to be gained by forcing it. What I'd sort of assumed we would do with the contrib scripts is major.minor, where a bump in the minor number is for a compatible upgrade (ie, run ALTER EXTENSION UPDATE and you're good) while a bump in the major number would be for incompatible changes. Otherwise I fear people will try to make the numbers match their package version number, which will either create stupid installation script sequences or stupid package version numbers, like those peculiar fellows who change the shared library version number in accordance with their package version number. I hear you, but even if we did restrict script versions to integers, people would still be tempted to sync them with some part of their package version number, and then they'd still get burnt. I think this is more a matter for documentation of how-you-should-use-this than something we can try to force programmatically. This would of course also simplify many other aspects about which version numbers to allow and how to compare them. It would enable comparisons, but we don't seem to need those after all. I don't think it really solves any problems in filename parsing, unless you'd like to disallow digits in extension names ... 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] Add support for logging the current role
Stephen Frost sfr...@snowman.net writes: * Tom Lane (t...@sss.pgh.pa.us) wrote: Yeah, I thought what was supposed to be emitted was the value of current_user, not SQL's weird definition of what SET ROLE means. current_user uses GetUserNameFromId() and goes through the cache lookups to get there. I was using what show_role() returns (which is also what 'show role;' returns). I'd be happy to make it emit an empty string when 'none' is returned though. Well, that just doesn't seem useful to me in the real world. If I were using this, I would expect it to emit a real user name that matches the currently applied permissions checking. All the time. show role does what it does because the SQL standard says so, not because anybody outside the standards committee thinks that's a sane definition. 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Tom Lane t...@sss.pgh.pa.us wrote: It might be worth trying to clean up those warn_unused_result things, if other people are seeing those. In `make world` I'm seeing: scan.c: In function *yy_try_NUL_trans*: scan.c:16256: warning: unused variable *yyg* -- elog.c: In function *write_console*: elog.c:1708: warning: ignoring return value of *write*, declared with attribute warn_unused_result elog.c: In function *write_pipe_chunks*: elog.c:2401: warning: ignoring return value of *write*, declared with attribute warn_unused_result elog.c:2410: warning: ignoring return value of *write*, declared with attribute warn_unused_result -- common.c: In function *handle_sigint*: common.c:247: warning: ignoring return value of *write*, declared with attribute warn_unused_result common.c:250: warning: ignoring return value of *write*, declared with attribute warn_unused_result common.c:251: warning: ignoring return value of *write*, declared with attribute warn_unused_result -- option.c: In function *parseCommandLine*: option.c:92: warning: ignoring return value of *getcwd*, declared with attribute warn_unused_result option.c: In function *get_pkglibdir*: option.c:336: warning: ignoring return value of *fgets*, declared with attribute warn_unused_result Example of a compile line showing a warning: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -g -I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -c -o elog.o elog.c -MMD -MP -MF .deps/elog.Po -Kevin -- 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 support for logging the current role
* Tom Lane (t...@sss.pgh.pa.us) wrote: Well, that just doesn't seem useful to me in the real world. If I were using this, I would expect it to emit a real user name that matches the currently applied permissions checking. All the time. I wouldn't have ever thought to use %U w/o %u, to be honest. Unless I'm missing something though, this change would just be emitting what show_session_authorization() returns when show_role() returns 'none'. That's certainly fine by me. show role does what it does because the SQL standard says so, not because anybody outside the standards committee thinks that's a sane definition. Guess it actually makes some sense to me. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Debian readline/libedit breakage
Stephen Frost wrote: -- Start of PGP signed section. * Bruce Momjian (br...@momjian.us) wrote: Well, we are going down a slippery slope if we think the click-through installers are OK to use readline and distribute because we supply the source for the installers --- that then requires anyone using the binaries (or libraries) in those installers to also supply the source code, e.g. GPL. If they build binaries which include the GPL'd readline, then there's a (potential) issue, sure. I'm not sure what system you're looking at, but readline isn't linked in by libpq today and I can't imagine it ever being linked to it. It is true that readline is not linked to libpq, but that muddies the waters. Notice that Dave said the source to Postgres is distributed, not that psql source is distributed, meaning he didn't make the distinction between psql and the complete source, and most users aren't going to understand that distinction. If they're using the binaries which the community provides, I really don't believe there's any issue. It's possible someone would ask for the source code for that psql binary, but that shouldn't/wouldn't be hard for them to produce for the community psql. If they're building their own binaries of psql which they've modified *and* have linked in with readline, then they've put themselves into a position where FSF or someone could complain. I'd recommend they not do that, so as to avoid the issue. True. I just hate to have anything in a packaged distribution that has any GPL requirement, even if it is a binary that no one can link to. Call me paranoid, but I see it as marketing confusion for us. :-( I am not saying they have to, but falling back to the oh we give source code for the click-through installers is not a position we can fall back on without affecting our users. I really don't follow the logic here. Are you suggesting that people take psql and *embed* it into their own binaries? If there's really that much concern over it, presumably the installers could be built w/o readline support. That'd probably be more comfortable for me anyway, since then psql on Windows would behave like every other Windows app. ;) (j/k..) psql used to use the native Windows line editing ability --- has that changed? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Debian readline/libedit breakage
Stephen Frost wrote: -- Start of PGP signed section. * Bruce Momjian (br...@momjian.us) wrote: I just posted on this. The risk is to people using the packages --- the packages themselves include the source as an option, so they are fine, but everyone using those packages would also be required to distribute source, which is a restriction we have avoided in the past. I think you may want to reread the GPL on this. They're not actually required to distribute source *with* the binaries (hell, Debian doesn't..) as long as they are willing to produce it if asked. And that's the source for the binaries which actually depend on the GPL'd code, eg, the community-built psql binary that you're talking about here.. They don't have to provide source for everything on the CD or something (again, Debian has a non-free section also..). Yes, I understand very well the source does not have to be with the binary. I am trying to avoid that non-BSD-licensed section in our installers. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us wrote: It might be worth trying to clean up those warn_unused_result things, if other people are seeing those. elog.c: In function *write_console*: elog.c:1708: warning: ignoring return value of *write*, declared with attribute warn_unused_result elog.c: In function *write_pipe_chunks*: elog.c:2401: warning: ignoring return value of *write*, declared with attribute warn_unused_result elog.c:2410: warning: ignoring return value of *write*, declared with attribute warn_unused_result -- common.c: In function *handle_sigint*: common.c:247: warning: ignoring return value of *write*, declared with attribute warn_unused_result common.c:250: warning: ignoring return value of *write*, declared with attribute warn_unused_result common.c:251: warning: ignoring return value of *write*, declared with attribute warn_unused_result In at least some of these cases, I think ignoring the write() result is intentional, because there's really nothing useful we can do about it if it fails (oh, you wish we'd log a failure to write to the log?). Would you check whether just casting the function result to (void) shuts it up? option.c: In function *parseCommandLine*: option.c:92: warning: ignoring return value of *getcwd*, declared with attribute warn_unused_result option.c: In function *get_pkglibdir*: option.c:336: warning: ignoring return value of *fgets*, declared with attribute warn_unused_result These look like they probably are genuine bugs, or if not bugs at least the kind of sloppy coding the warning is meant to catch. 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] Debian readline/libedit breakage
* Bruce Momjian (br...@momjian.us) wrote: psql used to use the native Windows line editing ability --- has that changed? *that* I couldn't tell you.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Tom Lane t...@sss.pgh.pa.us wrote: Would you check whether just casting the function result to (void) shuts it up? Casting the result to (void) didn't change the warning. It shut up when I declared a local variable and assigned the value to it (which was then never used). -Kevin -- 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] Debian readline/libedit breakage
On 02/17/2011 11:22 AM, Bruce Momjian wrote: psql used to use the native Windows line editing ability --- has that changed? When did it? Ad what native windows line editing ability are you referring to? 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] Debian readline/libedit breakage
Andrew Dunstan wrote: On 02/17/2011 11:22 AM, Bruce Momjian wrote: psql used to use the native Windows line editing ability --- has that changed? When did it? Ad what native windows line editing ability are you referring to? There is native Windows editing like arrows, etc and history, though the history is not kept between sessions. If windows is now using readline, then odds are we are shipping libreadline to make that happen, and we are then linking using a supplied GPL library (and we don't have the OS-installed exception). I hope I am wrong. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 support for logging the current role
* Robert Haas (robertmh...@gmail.com) wrote: Ugg, wait a minute. This not only adds %U; it also changes the behavior of %u, which I don't think we've agreed on. Also, emitting 'none' when not SET ROLE has been done is pretty ugly. I'm back to thinking we need to push this out to 9.2 and take more time to think about this. %u, user_name, etc changes reverted. %U now always returns the role currently being used for permissions checks, by using show_session_authorization() when show_role() returns 'none'. Ditto for CSV updates. git log below, re-based patch attached. All regression tests passed, tested with log_line_prefix and csvlog also, all looks good to me. Robert, if you say this has to be punted to 9.2 again, I'm giving up. ;) Thanks, Stephen *** a/doc/src/sgml/config.sgml --- b/doc/src/sgml/config.sgml *** *** 3562,3568 local0.*/var/log/postgresql /row row entryliteral%u/literal/entry ! entryUser name/entry entryyes/entry /row row --- 3562,3579 /row row entryliteral%u/literal/entry ! entryAuthenticated user name, the user name that the user used ! to authenticate to productnamePostgreSQL/productname with. ! entryyes/entry ! /row ! row ! entryliteral%U/literal/entry ! entryCurrent role being used for permissions checking, can be ! set with commandSET ROLE/ or commandSET SESSION ! AUTHORIZATION/ (only allowed for superusers); ! Note: Log messages from inside literalSECURITY DEFINER/ ! functions will show the calling role, not the effective role ! inside the literalSECURITY DEFINER/ function/entry entryyes/entry /row row *** *** 3790,3795 FROM pg_stat_activity; --- 3801,3807 with these columns: timestamp with milliseconds, user name, + current role name, database name, process ID, client host:port number, *** *** 3820,3825 CREATE TABLE postgres_log --- 3832,3838 ( log_time timestamp(3) with time zone, user_name text, + curr_role text, database_name text, process_id integer, connection_from text, *** a/src/backend/commands/variable.c --- b/src/backend/commands/variable.c *** *** 847,852 assign_session_authorization(const char *value, bool doit, GucSource source) --- 847,857 return result; } + /* + * function to return the stored session username, needed because we + * can't do catalog lookups when possibly being called after an error, + * eg: from elog.c or part of GUC handling. + */ const char * show_session_authorization(void) { *** *** 972,977 assign_role(const char *value, bool doit, GucSource source) --- 977,987 return result; } + /* + * function to return the stored role username, needed because we + * can't do catalog lookups when possibly being called after an error, + * eg: from elog.c or part of GUC handling. + */ const char * show_role(void) { *** a/src/backend/utils/error/elog.c --- b/src/backend/utils/error/elog.c *** *** 65,70 --- 65,71 #include access/transam.h #include access/xact.h + #include commands/variable.h #include libpq/libpq.h #include libpq/pqformat.h #include mb/pg_wchar.h *** *** 1777,1782 log_line_prefix(StringInfo buf, ErrorData *edata) --- 1778,1795 int format_len; int i; + /* gather current session and role names */ + const char *session_auth = show_session_authorization(); + const char *role_auth = show_role(); + + /* what we'll actually log as current role, based on if + * a set role has been done or not */ + char *curr_role = role_auth; + + /* if show_role() returns 'none', then we log the session user instead */ + if (strcmp(role_auth,none) == 0) + curr_role = session_auth; + /* * This is one of the few places where we'd rather not inherit a static * variable's value from the postmaster. But since we will, reset it when *** *** 1832,1837 log_line_prefix(StringInfo buf, ErrorData *edata) --- 1845,1853 appendStringInfoString(buf, username); } break; + case 'U': + appendStringInfoString(buf, curr_role); + break; case 'd': if (MyProcPort) { *** *** 1967,1972 write_csvlog(ErrorData *edata) --- 1983,2000 /* has counter been reset in current process? */ static int log_my_pid = 0; + /* pull the session authorization */ + const char *session_auth = show_session_authorization(); + const char *role_auth = show_role(); + + /* what we'll actually log as current role, based
Re: [HACKERS] Debian readline/libedit breakage
On 02/17/2011 11:44 AM, Bruce Momjian wrote: Andrew Dunstan wrote: On 02/17/2011 11:22 AM, Bruce Momjian wrote: psql used to use the native Windows line editing ability --- has that changed? When did it? Ad what native windows line editing ability are you referring to? There is native Windows editing like arrows, etc and history, though the history is not kept between sessions. If windows is now using readline, then odds are we are shipping libreadline to make that happen, and we are then linking using a supplied GPL library (and we don't have the OS-installed exception). I hope I am wrong. Readline has always been disabled on Windows builds AFAIK. Just look at the buildfarm traces. Here's an example from http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouthdt=2011-02-17%2015%3A30%3A03stg=configure configure: WARNING: *** Readline does not work on MinGW --- disabling It's not used in MSVC either, IIRC. 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] Debian readline/libedit breakage
Andrew Dunstan wrote: On 02/17/2011 11:44 AM, Bruce Momjian wrote: Andrew Dunstan wrote: On 02/17/2011 11:22 AM, Bruce Momjian wrote: psql used to use the native Windows line editing ability --- has that changed? When did it? Ad what native windows line editing ability are you referring to? There is native Windows editing like arrows, etc and history, though the history is not kept between sessions. If windows is now using readline, then odds are we are shipping libreadline to make that happen, and we are then linking using a supplied GPL library (and we don't have the OS-installed exception). I hope I am wrong. Readline has always been disabled on Windows builds AFAIK. Just look at the buildfarm traces. Here's an example from http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouthdt=2011-02-17%2015%3A30%3A03stg=configure configure: WARNING: *** Readline does not work on MinGW --- disabling It's not used in MSVC either, IIRC. OK, I was only responding to Stephen Frost who said psql did not behave like other Windows apps. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] sepgsql contrib module
The attached patch removes rules to build a policy package for regression test and modifies documentation part to introduce steps to run the test. Thanks, -- NEC Europe Ltd, Global Competence Center KaiGai Kohei kohei.kai...@eu.nec.com -Original Message- From: Kohei Kaigai Sent: 15 February 2011 18:27 To: 'Robert Haas'; Tom Lane Cc: Andrew Dunstan; Stephen Frost; KaiGai Kohei; PgHacker Subject: RE: [HACKERS] sepgsql contrib module -Original Message- From: Robert Haas [mailto:robertmh...@gmail.com] Sent: 15 February 2011 16:52 To: Tom Lane Cc: Andrew Dunstan; Kohei Kaigai; Stephen Frost; KaiGai Kohei; PgHacker Subject: Re: [HACKERS] sepgsql contrib module On Tue, Feb 15, 2011 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Those are good points. My point was just that you can't actually build that file at the time you RUN the regression tests, because you have to build it first, then install it, then run the regression tests. It could be a separate target, like 'make policy', but I don't think it works to make it part of 'make installcheck'. So? Once you admit that you can do that, it's a matter of a couple more lines to make the installcheck target depend on the policy target iff selinux was enabled. Sure, you could do that, but I don't see what problem it would fix. You'd still have to build and manually install the policy before you could run make installcheck. And once you've done that, you don't need to rebuild it every future time you run make installcheck. Oh, I see: you're pointing out the root-only semodule step that has to be done in between there. Good point. But the current arrangement is still a mistake: the required contents of sepgsql-regtest.pp depend on the configuration of the test system, which can't be known at build time. So what we should do is offer a make policy target and alter the test instructions to say you should do that and then run semodule. Or maybe just put the whole make -f /usr/share/selinux/devel/Makefile dance into the instructions --- it doesn't look to me like our makefile infrastructure really has anything useful to add to that. Yeah, agreed. I also agree with this direction. The policy type depends on individual installations, it is not easy to assume on build time. Please wait for a small patch to remove this rule from Makefile and update documentation. As a side note, we can have a build option that does not require selinux enabled. The reason why Makefile of selinux tries to /selinux/mls is that we don't specify MLS=1 or MLS=0 explicitly. IIRC, the specfile of RHEL/Fedora gives all the Makefile parameters explicitly, thus, selinux does not need to be enabled on the build server. However, it is not a solution in this case. It is not easy to estimate the required policy type and existence of MLS support on build time. Thanks, -- NEC Europe Ltd, Global Competence Center KaiGai Kohei kohei.kai...@eu.nec.com sepgsql-policy.1.patch Description: sepgsql-policy.1.patch -- 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
2011/2/17 Florian Pflug f...@phlo.org On Feb17, 2011, at 01:14 , Oliver Jowett wrote: Any suggestions about how the JDBC driver can express the query to get the behavior that it wants? Specifically, the driver wants to call a particular function with N OUT or INOUT parameters (and maybe some other IN parameters too) and get a resultset with N columns back. There's no sane way to do that, I fear. You could of course look up the function definition in the catalog before actually calling it, but with overloading and polymorphic types finding the right pg_proc entry seems awfully complex. Your best option is probably to just document this caveat... But there still is a bug in the JDBC driver as I originally documented it. Even if you say it's not simple to know whether the signature is actually a single UDT with 6 attributes or just 6 OUT parameters, the result is wrong (as stated in my original mail): The nested UDT structure completely screws up fetching results. This is what I get with JDBC: PreparedStatement stmt = connection.prepareStatement(select * from p_enhance_address2()); ResultSet rs = stmt.executeQuery(); while (rs.next()) { System.out.println(# of columns: + rs.getMetaData().getColumnCount()); System.out.println(rs.getObject(1)); } Output: # of columns: 6 ((Parliament Hill,77),NW31A9) The result set meta data correctly state that there are 6 OUT columns. But only the first 2 are actually fetched (because of a nested UDT)...
[HACKERS] rewrite of RECENTLY DEAD tuples
Hello list, ATRewriteTable in tablecmds.c uses SnapshotNow to rewrite and thus does not copy RECENTLY DEAD tuples. But copy_heap_data in cluster.c uses SnapshotAny and copys RECENTLY DEAD tuples to the new heap file. I don't understand why it is not needed in the first case. In the second case I guess that there may be still a transaction with an older snapshot running which should be able to open the rewrited table and see the older (RECENTLY DEAD) tuple. Why must a transaction in the first case not be able to do so also? Regards Benjamin -- 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] SSI bug?
hi, YAMAMOTO Takashi wrote: with your previous patch or not? With, thanks. i tried. unfortunately i can still reproduce the original loop problem. WARNING: [0] target 0xbb51ef18 tag 4000:4017:7e3:78:0 prior 0xbb51f148 next 0xb b51edb0 WARNING: [1] target 0xbb51f148 tag 4000:4017:7e3:77:0 prior 0xbb51ef90 next 0xb b51ef18 WARNING: [2] target 0xbb51ef90 tag 4000:4017:7e3:74:0 prior 0xbb51edb0 next 0xb b51f148 WARNING: [3] target 0xbb51edb0 tag 4000:4017:7e3:71:0 prior 0xbb51ef18 next 0xb b51ef90 WARNING: found a loop YAMAMOTO Takashi -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] SSI bug?
hi, YAMAMOTO Takashi wrote: might be unrelated to the loop problem, but... Aha! I think it *is* related. There were several places where data was uninitialized here; mostly because Dan was working on this piece while I was working on separate issues which added the new fields. I missed the interaction on integrating the two efforts. :-( The uninitialized fields could lead to all the symptoms you saw. I've reviewed, looking for other similar issues and didn't find any. Could you try the attached patch and see if this fixes the issues you've seen? with your previous patch or not? YAMAMOTO Takashi -Kevin -- 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] SSI bug?
hi, might be unrelated to the loop problem, but... i got the following SEGV when runnning vacuum on a table. (the line numbers in predicate.c is different as i have local modifications.) oldlocktag.myTarget was NULL. it seems that TransferPredicateLocksToNewTarget sometimes use stack garbage for newpredlocktag.myTarget. vacuum on the table succeeded with the attached patch. the latter part of the patch was necessary to avoid targetList corruption, which later seems to make DeleteChildTargetLocks loop inifinitely. YAMAMOTO Takashi #0 0x0823cf6c in PredicateLockAcquire (targettag=0xbfbfa734) at predicate.c:1835 #1 0x0823f18a in PredicateLockPage (relation=0x99b4dcf0, blkno=1259) at predicate.c:2206 #2 0x080ac978 in _bt_search (rel=0x99b4dcf0, keysz=2, scankey=0x99a05040, nextkey=0 '\0', bufP=0xbfbfa894, access=1) at nbtsearch.c:97 #3 0x080a996d in _bt_pagedel (rel=0x99b4dcf0, buf=value optimized out, stack=0x0) at nbtpage.c:1059 #4 0x080aacc2 in btvacuumscan (info=0xbfbfbcc4, stats=0x99a01328, callback=0x8184d50 lazy_tid_reaped, callback_state=0x99a012e0, cycleid=13675) at nbtree.c:981 #5 0x080ab15c in btbulkdelete (fcinfo=0xbfbfb9e0) at nbtree.c:573 #6 0x082fde74 in FunctionCall4 (flinfo=0x99b86958, arg1=3217013956, arg2=0, arg3=135810384, arg4=2577404640) at fmgr.c:1437 #7 0x080a4fd0 in index_bulk_delete (info=0xbfbfbcc4, stats=0x0, callback=0x8184d50 lazy_tid_reaped, callback_state=0x99a012e0) at indexam.c:738 #8 0x08184cd4 in lazy_vacuum_index (indrel=0x99b4dcf0, stats=0x99a023e0, vacrelstats=0x99a012e0) at vacuumlazy.c:938 #9 0x081854b6 in lazy_vacuum_rel (onerel=0x99b47650, vacstmt=0x99b059d0, bstrategy=0x99a07018, scanned_all=0xbfbfcfd8 ) at vacuumlazy.c:762 #10 0x08184265 in vacuum_rel (relid=16424, vacstmt=0x99b059d0, do_toast=1 '\001', for_wraparound=0 '\0', scanned_all=0xbfbfcfd8 ) at vacuum.c:978 #11 0x081845ea in vacuum (vacstmt=0x99b059d0, relid=0, do_toast=1 '\001', bstrategy=0x0, for_wraparound=0 '\0', isTopLevel=1 '\001') at vacuum.c:230 #12 0xbbab50c3 in pgss_ProcessUtility (parsetree=0x99b059d0, queryString=0x99b05018 vacuum (verbose,analyze) pgfs.dirent;, params=0x0, isTopLevel=1 '\001', dest=0x99b05b80, completionTag=0xbfbfd21a ) at pg_stat_statements.c:603 #13 0x082499ea in PortalRunUtility (portal=0x99b33018, utilityStmt=0x99b059d0, isTopLevel=1 '\001', dest=0x99b05b80, completionTag=0xbfbfd21a ) at pquery.c:1191 #14 0x0824a79e in PortalRunMulti (portal=0x99b33018, isTopLevel=4 '\004', dest=0x99b05b80, altdest=0x99b05b80, completionTag=0xbfbfd21a ) at pquery.c:1298 #15 0x0824b21a in PortalRun (portal=0x99b33018, count=2147483647, isTopLevel=1 '\001', dest=0x99b05b80, altdest=0x99b05b80, completionTag=0xbfbfd21a ) at pquery.c:822 #16 0x08247dc7 in exec_simple_query ( query_string=0x99b05018 vacuum (verbose,analyze) pgfs.dirent;) at postgres.c:1059 #17 0x08248a79 in PostgresMain (argc=2, argv=0xbb912650, username=0xbb9125c0 takashi) at postgres.c:3943 #18 0x0820e231 in ServerLoop () at postmaster.c:3590 #19 0x0820ef88 in PostmasterMain (argc=3, argv=0xbfbfe59c) at postmaster.c:1110 #20 0x081b6439 in main (argc=3, argv=0xbfbfe59c) at main.c:199 (gdb) list 1830 offsetof(PREDICATELOCK, xactLink)); 1831 1832oldlocktag = predlock-tag; 1833Assert(oldlocktag.myXact == sxact); 1834oldtarget = oldlocktag.myTarget; 1835oldtargettag = oldtarget-tag; 1836 1837if (TargetTagIsCoveredBy(oldtargettag, *newtargettag)) 1838{ 1839uint32 oldtargettaghash; (gdb) diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c index 722d0f8..4dde6ae 100644 --- a/src/backend/storage/lmgr/predicate.c +++ b/src/backend/storage/lmgr/predicate.c @@ -2537,8 +2558,8 @@ TransferPredicateLocksToNewTarget(const PREDICATELOCKTARGETTAG oldtargettag, if (!found) { SHMQueueInit((newtarget-predicateLocks)); - newpredlocktag.myTarget = newtarget; } + newpredlocktag.myTarget = newtarget; oldpredlock = (PREDICATELOCK *) SHMQueueNext((oldtarget-predicateLocks), @@ -2588,10 +2609,12 @@ TransferPredicateLocksToNewTarget(const PREDICATELOCKTARGETTAG oldtargettag, outOfShmem = true; goto exit; } - SHMQueueInsertBefore((newtarget-predicateLocks), - (newpredlock-targetLink)); - SHMQueueInsertBefore((newpredlocktag.myXact-predicateLocks), -
[HACKERS] default_tablespace
Hi Hackers, After reviewing docs and searching web cannot find out how to determine the default tablespace of a user? Like: select spcname from blab where roloid = ; Is this possible? Thank you for your time. -- 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] pika failing since the per-column collation patch
Le 14 févr. 2011 à 19:27, Rémi Zara a écrit : Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit : It's only failing on this one machine, but there isn't anything platform-specific in this code, so I'd look for memory management faults on the code or a compiler problem. Try with lower optimization for a start. Same failure with -O0 (and more shared memory). Hi, Without me changing anything (still at -O0), the same error occurred but at the installCheck step, rather than the check step (which passed) Anything else to try ? Regards, Rémi Zara -- 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Tom Lane t...@sss.pgh.pa.us wrote: In at least some of these cases, I think ignoring the write() result is intentional, because there's really nothing useful we can do about it if it fails (oh, you wish we'd log a failure to write to the log?). I know that in Java you can get a positive number less than the full size as an indication that part of the block was written, and you must loop to write until you get all of it written (or get an error return). At this page, it appears that the same is true of the write function in C: http://www.gnu.org/s/libc/manual/html_node/I_002fO-Primitives.html Quoting from that page: | The return value is the number of bytes actually written. This may | be size, but can always be smaller. Your program should always | call write in a loop, iterating until all the data is written. Isn't that the write function we're calling? If so, are you maintaining that the gnu.org documentation of this function is wrong? -Kevin -- 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] Debian readline/libedit breakage
On 02/17/2011 11:58 AM, Bruce Momjian wrote: Andrew Dunstan wrote: On 02/17/2011 11:44 AM, Bruce Momjian wrote: Andrew Dunstan wrote: On 02/17/2011 11:22 AM, Bruce Momjian wrote: psql used to use the native Windows line editing ability --- has that changed? When did it? Ad what native windows line editing ability are you referring to? There is native Windows editing like arrows, etc and history, though the history is not kept between sessions. If windows is now using readline, then odds are we are shipping libreadline to make that happen, and we are then linking using a supplied GPL library (and we don't have the OS-installed exception). I hope I am wrong. Readline has always been disabled on Windows builds AFAIK. Just look at the buildfarm traces. Here's an example from http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouthdt=2011-02-17%2015%3A30%3A03stg=configure configure: WARNING: *** Readline does not work on MinGW --- disabling It's not used in MSVC either, IIRC. OK, I was only responding to Stephen Frost who said psql did not behave like other Windows apps. I think both of you have possibly been under a misapprehension. All this discussion about the Windows installers is entirely irrelevant to this thread, ISTM, since there is no readline use in them. FWIW, the only interactively usable version of psql for windows I know of is the one that runs under Cygwin. It can be build with readline and works as expected. 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] Debian readline/libedit breakage
Andrew Dunstan wrote: On 02/17/2011 11:58 AM, Bruce Momjian wrote: Andrew Dunstan wrote: On 02/17/2011 11:44 AM, Bruce Momjian wrote: Andrew Dunstan wrote: On 02/17/2011 11:22 AM, Bruce Momjian wrote: psql used to use the native Windows line editing ability --- has that changed? When did it? Ad what native windows line editing ability are you referring to? There is native Windows editing like arrows, etc and history, though the history is not kept between sessions. If windows is now using readline, then odds are we are shipping libreadline to make that happen, and we are then linking using a supplied GPL library (and we don't have the OS-installed exception). I hope I am wrong. Readline has always been disabled on Windows builds AFAIK. Just look at the buildfarm traces. Here's an example from http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouthdt=2011-02-17%2015%3A30%3A03stg=configure configure: WARNING: *** Readline does not work on MinGW --- disabling It's not used in MSVC either, IIRC. OK, I was only responding to Stephen Frost who said psql did not behave like other Windows apps. I think both of you have possibly been under a misapprehension. All this discussion about the Windows installers is entirely irrelevant to this thread, ISTM, since there is no readline use in them. OK, that's what I thought. FWIW, the only interactively usable version of psql for windows I know of is the one that runs under Cygwin. It can be build with readline and works as expected. Uh, don't we have a psql built via MSVC? Doesn't it work interactively? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] contrib loose ends: 9.0 to 9.1 incompatibilities
So, after some testing, attached are two different fixed-up versions of pg_tgrm's update-from-unpackaged script. The first one leaves the parameter lists of some GIN support functions different from what they would be if you installed pg_trgrm fresh in 9.1. The second one fixes the parameter lists too, by means of really ugly direct UPDATEs on pg_proc. I'm unsure which one to apply --- any opinions? It's worth noting that both versions still leave the pg_trgm opclasses a bit different from a fresh install, because the added operators are loose in the opfamily rather than being bound into the opclass. This hasn't got any real functional effect, but if you were feeling paranoid you could worry about whether the two different states could cause problems for future versions of the update script. As far as I can see, the only thing we could realistically do about this with the tools at hand is to change pg_trgm's install script so that it also creates the new-in-9.1 entries loose. That seems a tad ugly, but depending on where you stand on the paranoia scale you might think it's a good idea. There is definitely no point in that refinement unless we update the function parameter lists, though. Comments? regards, tom lane /* contrib/pg_trgm/pg_trgm--unpackaged--1.0.sql */ ALTER EXTENSION pg_trgm ADD function set_limit(real); ALTER EXTENSION pg_trgm ADD function show_limit(); ALTER EXTENSION pg_trgm ADD function show_trgm(text); ALTER EXTENSION pg_trgm ADD function similarity(text,text); ALTER EXTENSION pg_trgm ADD function similarity_op(text,text); ALTER EXTENSION pg_trgm ADD operator %(text,text); ALTER EXTENSION pg_trgm ADD type gtrgm; ALTER EXTENSION pg_trgm ADD function gtrgm_in(cstring); ALTER EXTENSION pg_trgm ADD function gtrgm_out(gtrgm); ALTER EXTENSION pg_trgm ADD function gtrgm_consistent(internal,text,integer,oid,internal); ALTER EXTENSION pg_trgm ADD function gtrgm_compress(internal); ALTER EXTENSION pg_trgm ADD function gtrgm_decompress(internal); ALTER EXTENSION pg_trgm ADD function gtrgm_penalty(internal,internal,internal); ALTER EXTENSION pg_trgm ADD function gtrgm_picksplit(internal,internal); ALTER EXTENSION pg_trgm ADD function gtrgm_union(bytea,internal); ALTER EXTENSION pg_trgm ADD function gtrgm_same(gtrgm,gtrgm,internal); ALTER EXTENSION pg_trgm ADD operator family gist_trgm_ops using gist; ALTER EXTENSION pg_trgm ADD operator class gist_trgm_ops using gist; ALTER EXTENSION pg_trgm ADD operator family gin_trgm_ops using gin; ALTER EXTENSION pg_trgm ADD operator class gin_trgm_ops using gin; -- These functions had different names/signatures in 9.0. We can't just -- drop and recreate them because they are linked into the GIN opclass, -- so we need some hacks. -- First, absorb them into the extension under their old names. ALTER EXTENSION pg_trgm ADD function gin_extract_trgm(text, internal); ALTER EXTENSION pg_trgm ADD function gin_extract_trgm(text, internal, int2, internal, internal); ALTER EXTENSION pg_trgm ADD function gin_trgm_consistent(internal,smallint,text,integer,internal,internal); -- Fix the names, and then do CREATE OR REPLACE to adjust the function -- bodies to be correct (ie, reference the correct C symbol). We do not -- attempt to change the parameter lists, however. It's not necessary -- since GIN doesn't care, and there's no clean way to do it. ALTER FUNCTION gin_extract_trgm(text, internal) RENAME TO gin_extract_value_trgm; CREATE OR REPLACE FUNCTION gin_extract_value_trgm(text, internal) RETURNS internal AS 'MODULE_PATHNAME' LANGUAGE C IMMUTABLE STRICT; ALTER FUNCTION gin_extract_trgm(text, internal, int2, internal, internal) RENAME TO gin_extract_query_trgm; CREATE OR REPLACE FUNCTION gin_extract_query_trgm(text, internal, int2, internal, internal) RETURNS internal AS 'MODULE_PATHNAME' LANGUAGE C IMMUTABLE STRICT; -- gin_trgm_consistent didn't change name, so nothing more to do for it. -- These were not in 9.0: CREATE FUNCTION similarity_dist(text,text) RETURNS float4 AS 'MODULE_PATHNAME' LANGUAGE C STRICT IMMUTABLE; CREATE OPERATOR - ( LEFTARG = text, RIGHTARG = text, PROCEDURE = similarity_dist, COMMUTATOR = '-' ); CREATE FUNCTION gtrgm_distance(internal,text,int,oid) RETURNS float8 AS 'MODULE_PATHNAME' LANGUAGE C IMMUTABLE STRICT; -- Add new stuff to the operator classes. Note this will result in the -- added stuff being loose in the operator family, rather than bound -- into the operator class as it would be when creating the extension -- from scratch. That shouldn't be problematic. ALTER OPERATOR FAMILY gist_trgm_ops USING gist ADD OPERATOR2 - (text, text) FOR ORDER BY pg_catalog.float_ops, OPERATOR3 pg_catalog.~~ (text, text), OPERATOR4 pg_catalog.~~* (text, text), FUNCTION8 (text, text) gtrgm_distance (internal, text, int, oid); ALTER OPERATOR FAMILY gin_trgm_ops USING gin ADD OPERATOR3
Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us wrote: Would you check whether just casting the function result to (void) shuts it up? Casting the result to (void) didn't change the warning. It shut up when I declared a local variable and assigned the value to it (which was then never used). Too bad. I believe gcc 4.6 will warn about *that*, so it's not going to be much of an improvement for long. 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Kevin Grittner kevin.gritt...@wicourts.gov writes: I know that in Java you can get a positive number less than the full size as an indication that part of the block was written, and you must loop to write until you get all of it written (or get an error return). At this page, it appears that the same is true of the write function in C: This is appropriate when writing to sockets etc, where the kernel is willing to reflect details like packet boundaries back to userspace. I have never seen nor heard of it being true for writes to disk files, except for the case of out-of-disk-space, in which it is quite unlikely that looping is a good thing to do. 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] Debian readline/libedit breakage
* Bruce Momjian (br...@momjian.us) wrote: OK, I was only responding to Stephen Frost who said psql did not behave like other Windows apps. I don't actually run psql or PG on Windows at all, I just presumed it did since you were bringing up concerns about it in the Windows installers. Ah well, sorry for the confusion. :) Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Debian readline/libedit breakage
On 02/17/2011 12:13 PM, Bruce Momjian wrote: FWIW, the only interactively usable version of psql for windows I know of is the one that runs under Cygwin. It can be build with readline and works as expected. Uh, don't we have a psql built via MSVC? Doesn't it work interactively? Not if you want readline. And in my book that's a requirement of a psql that's usable interactively. It's pretty horrible to use without 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
On 02/17/2011 12:19 PM, Tom Lane wrote: Kevin Grittnerkevin.gritt...@wicourts.gov writes: Tom Lanet...@sss.pgh.pa.us wrote: Would you check whether just casting the function result to (void) shuts it up? Casting the result to (void) didn't change the warning. It shut up when I declared a local variable and assigned the value to it (which was then never used). Too bad. I believe gcc 4.6 will warn about *that*, so it's not going to be much of an improvement for long. Ugh. Isn't there some sort of pragma or similar we can use to shut it up? 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] default_tablespace
On Wed, Feb 16, 2011 at 03:59:13PM -0800, carl clemens wrote: - Hi Hackers, - - After reviewing docs and searching web - cannot find out how to determine the default tablespace - of a user? - - Like: - - select spcname from blab where roloid = ; - - Is this possible? - - Thank you for your time. - It doesn't appear to me that default tablespaces are assigned to a user, they're assigned to a database. A user can set the variable default_tablespace in their session to over-ride the database default, but that wouldn't be stored anywhere in the database (it's a client variable). you can find the OID for the default tablespace for a specific database in pg_database. more info: http://www.postgresql.org/docs/9.0/static/runtime-config-client.html#GUC-DEFAULT-TABLESPACE Dave -- 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] Debian readline/libedit breakage
Stephen Frost wrote: -- Start of PGP signed section. * Bruce Momjian (br...@momjian.us) wrote: I just posted on this. The risk is to people using the packages --- the packages themselves include the source as an option, so they are fine, but everyone using those packages would also be required to distribute source, which is a restriction we have avoided in the past. I think you may want to reread the GPL on this. They're not actually required to distribute source *with* the binaries (hell, Debian doesn't..) as long as they are willing to produce it if asked. And that's the source for the binaries which actually depend on the GPL'd code, eg, the community-built psql binary that you're talking about here.. They don't have to provide source for everything on the CD or something (again, Debian has a non-free section also..). In summary, our click-through installers and hopefully other packaged versions of Postgres don't distribute libreadline and rely on the OS-supplied version, which is a FSF exception. As I mentioned, distributing the installer source doesn't exempt others from having to GPL when they add to it (again, kind of rare because you can't link something to psql, but anyway, it is mostly perception). Debian distributes both Postgres and libreadline, so my guess is they don't think they can use that exception and therefore have a problem. And, again, libedit is not as hard as many of the problems we have solved. Since we have grown strong, I would love to see us reaching out to those satellite communities and helping them solve some of their problems, though, as people pointed out, in a way that does not take energy away from Postgres development. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Debian readline/libedit breakage
Andrew Dunstan wrote: On 02/17/2011 12:13 PM, Bruce Momjian wrote: FWIW, the only interactively usable version of psql for windows I know of is the one that runs under Cygwin. It can be build with readline and works as expected. Uh, don't we have a psql built via MSVC? Doesn't it work interactively? Not if you want readline. And in my book that's a requirement of a psql that's usable interactively. It's pretty horrible to use without it. Well, as horrible as other Windows apps. I will leave others to decide if that is usable. ;-) I am unclear if we would ship readline support on Windows even if we didn't have a license issue (no OS readline version on Windows). -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] rewrite of RECENTLY DEAD tuples
On Thu, Feb 17, 2011 at 09:38:51AM +0100, Benjamin S. wrote: ATRewriteTable in tablecmds.c uses SnapshotNow to rewrite and thus does not copy RECENTLY DEAD tuples. But copy_heap_data in cluster.c uses SnapshotAny and copys RECENTLY DEAD tuples to the new heap file. I don't understand why it is not needed in the first case. In the second case I guess that there may be still a transaction with an older snapshot running which should be able to open the rewrited table and see the older (RECENTLY DEAD) tuple. Why must a transaction in the first case not be able to do so also? Unlike VACUUM FULL and CLUSTER, ALTER TABLE rewrites are not MVCC-safe. No visibility-relevant information is preserved; all tuples get the xmin of the ALTER TABLE transaction. The table will look empty to snapshots predating the commit of the ALTER TABLE transaction. Compare TRUNCATE. All other things being equal, it would be nice for ALTER TABLE rewrites to become MVCC-safe. The main implication is that tuples not visible to us can cause the operation to fail. Example: CREATE TABLE t (x int); CREATE DOMAIN int_notnull AS int NOT NULL; INSERT INTO t VALUES (NULL); -- acquire a snapshot in some other session here DELETE FROM t; ALTER TABLE t ALTER x TYPE int_notnull; -- error converting deleted tuple If we also made the error message sufficiently informative, I'd wager this would be a net improvement for the average user. Thanks, nm -- 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 (for 9.1) string functions ( correct patch attached )
Erik Rijkers wrote: On Thu, July 29, 2010 22:43, Erik Rijkers wrote: Hi Pavel, In xfunc.sgml, I came across a function example (for use of VARIADIC in polymorphic functions), where the function name is concat(): (in the manual: 35.4.10. Polymorphic SQL Functions). Although that is not strictly wrong, it seems better to change that name when concat goes into core, as seems to be the plan. If you agree, it seems best to include this change in your patch and change that example function's name when the stringfunc patch gets applied. My apologies, the previous email had the wrong doc-patch attached. Here is the correct one. Applied for 9.1. Thanks. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname
Boszormenyi Zoltan wrote: Kevin Grittner ?rta: Michael Meskes mich...@fam-meskes.de wrote: All prior ECPG versions were fine because dynamic cursor names were only added in 9.0. Apparently only this one place was missed. So this is a bug in the new feature, however not such a major one that it warrants the complete removal IMO. I'd prefer to fix this in 9.0.1. As we are so late in the beta phase, we can live with that, hopefully you will find time by then to review the patch which is actually not that complex, only a bit large. The part of ECPGdo() that deals with auto-preparing statements is moved closer to calling ecpg_execute(), after the varargs are converted to stmt-inlist and -outlist. Hope this cleans it up a bit. Thanks. I think I get it now. To restate from another angle, to confirm my understanding: UPDATE WHERE CURRENT OF is working for cursors with the name hard-coded in the embedded statement, which is the only way cursor names were allowed to be specified prior to 9.0; 9.0 implements dynamic cursor names, allowing you to use a variable for the cursor name; but this one use of a cursor name isn't allowing a variable yet. Do I have it right? (If so, I now see why it would be considered a bug.) Yes, you understand it correctly. Did this ever get applied? If so, I can't find it. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Andrew Dunstan and...@dunslane.net wrote: Ugh. Isn't there some sort of pragma or similar we can use to shut it up? If that fails, maybe use some function like the below? That would also have the advantage of not relying on assumptions beyond the documented API, which I tend to feel good about no matter how sure I am that the implementation details upon which I'm relying won't change. No claims that this is good final form, especially when it comes to using ssize_t, but just trying to get across the general idea: void write_completely_ignore_errors(int filedes, const void *buffer, size_t size) { size_t t = 0; while (t size) { ssize_t n = write(filedes, buffer, size - t); if (n = 0) break; t += n; } } -Kevin -- 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] Rewrite, normal execution vs. EXPLAIN ANALYZE
Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: I seriously doubt that there are many applications out there that are actually depending on this aspect of rule execution; if anything, there are probably more that will see it as a bug. Changing EXPLAIN ANALYZE seems a bit less likely to break things for anyone depending on current behavior; Well, the point I was trying to make is that there may well be fewer people depending on the current behavior than there are people for whom the current behavior is wrong, only they don't know it because they've not seen a failure (or not seen one often enough to diagnose what's happening). This is of course merest speculation either way. But I don't feel that we need to necessarily treat rule behavior as graven in stone. Where are we on this? It seems it is an issue independent of writable common table expressions (wCTEs). -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Rewrite, normal execution vs. EXPLAIN ANALYZE
On Thu, Feb 17, 2011 at 1:04 PM, Bruce Momjian br...@momjian.us wrote: Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: I seriously doubt that there are many applications out there that are actually depending on this aspect of rule execution; if anything, there are probably more that will see it as a bug. Changing EXPLAIN ANALYZE seems a bit less likely to break things for anyone depending on current behavior; Well, the point I was trying to make is that there may well be fewer people depending on the current behavior than there are people for whom the current behavior is wrong, only they don't know it because they've not seen a failure (or not seen one often enough to diagnose what's happening). This is of course merest speculation either way. But I don't feel that we need to necessarily treat rule behavior as graven in stone. Where are we on this? It seems it is an issue independent of writable common table expressions (wCTEs). I believe that it's the same issue as this patch: https://commitfest.postgresql.org/action/patch_view?id=377 The status of that patch is that Tom promised to look at it two months ago and hasn't. It would be nice if someone else could pick it up. It's not good for our community to ignore patches that people have taken the trouble to write and submit. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Debian readline/libedit breakage
On Thu, 2011-02-17 at 10:49 +, Dave Page wrote: On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander mag...@hagander.net wrote: Probably readline but does it matter? We distribute the source to the click installers. Actually, we don't. We used to, but we don't at this point. Depends on your definition of distribute (and what part you are specifically referring to). There's no tarball, but the installer sources are on git.postgresql.org. Right, and that qualifies. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- 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] Debian readline/libedit breakage
On 02/17/2011 12:34 PM, Bruce Momjian wrote: Andrew Dunstan wrote: On 02/17/2011 12:13 PM, Bruce Momjian wrote: FWIW, the only interactively usable version of psql for windows I know of is the one that runs under Cygwin. It can be build with readline and works as expected. Uh, don't we have a psql built via MSVC? Doesn't it work interactively? Not if you want readline. And in my book that's a requirement of a psql that's usable interactively. It's pretty horrible to use without it. Well, as horrible as other Windows apps. I will leave others to decide if that is usable. ;-) I am unclear if we would ship readline support on Windows even if we didn't have a license issue (no OS readline version on Windows). Windows developers almost universally work from GUIs and not using console apps (and that's true of many Unix developers also, particularly those who can't recall a time when X-Windows wasn't almost universally available). Microsoft has de-emphasized console apps for 15 years. So the only people who are likely to be interested in using an enhanced psql on Windows are old Unix-heads like you and me. It's not worth a lot of effort, IMNSHO. 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] Rewrite, normal execution vs. EXPLAIN ANALYZE
Robert Haas wrote: On Thu, Feb 17, 2011 at 1:04 PM, Bruce Momjian br...@momjian.us wrote: Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote: I seriously doubt that there are many applications out there that are actually depending on this aspect of rule execution; if anything, there are probably more that will see it as a bug. Changing EXPLAIN ANALYZE seems a bit less likely to break things for anyone depending on current behavior; Well, the point I was trying to make is that there may well be fewer people depending on the current behavior than there are people for whom the current behavior is wrong, only they don't know it because they've not seen a failure (or not seen one often enough to diagnose what's happening). This is of course merest speculation either way. ?But I don't feel that we need to necessarily treat rule behavior as graven in stone. Where are we on this? ?It seems it is an issue independent of writable common table expressions (wCTEs). I believe that it's the same issue as this patch: https://commitfest.postgresql.org/action/patch_view?id=377 The status of that patch is that Tom promised to look at it two months ago and hasn't. It would be nice if someone else could pick it up. It's not good for our community to ignore patches that people have taken the trouble to write and submit. Oh, at least it is in the current commit-fest and was not lost. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] remove upsert example from docs
Marko Tiikkaja wrote: On 8/5/2010 9:44 PM, Merlin Moncure wrote: On Thu, Aug 5, 2010 at 2:09 PM, Tom Lanet...@sss.pgh.pa.us wrote: I was not persuaded that there's a real bug in practice. IMO, his problem was a broken trigger not broken upsert logic. Even if we conclude this is unsafe, simply removing the example is of no help to anyone. Well, the error handler is assuming that the unique_volation is coming from the insert made within the loop. This is obviously not a safe assumption in an infinite loop context. It should be double checking where the error was being thrown from -- but the only way I can think of to do that is to check sqlerrm. Yeah, this is a known problem with our exception system. If there was an easy and reliable way of knowing where the exception came from, I'm sure the example would include that. Or you arguing that if you're doing this, all dependent triggers must not throw unique violations up the exception chain? If he isn't, I am. I'm pretty sure you can break every example in the docs with a trigger (or a rule) you haven't thought through. A more useful response would be to supply a correct example. Agree: I'd go further I would argue to supply both the 'safe' and 'high concurrency (with caveat)' way. I'm not saying the example is necessarily bad, just that it's maybe not a good thing to be pointing as a learning example without qualifications. Then you get a lesson both on upsert methods and defensive error handling (barring objection, I'll provide that). The problem with the safe way is that it's not safe if called in a transaction with isolation level set to SERIALIZABLE. Good analysis. Documentation patch attached and applied. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml index c342916..d2e74dc 100644 *** a/doc/src/sgml/plpgsql.sgml --- b/doc/src/sgml/plpgsql.sgml *** BEGIN *** 2464,2470 INSERT INTO db(a,b) VALUES (key, data); RETURN; EXCEPTION WHEN unique_violation THEN ! -- do nothing, and loop to try the UPDATE again END; END LOOP; END; --- 2464,2470 INSERT INTO db(a,b) VALUES (key, data); RETURN; EXCEPTION WHEN unique_violation THEN ! -- Do nothing, and loop to try the UPDATE again. END; END LOOP; END; *** LANGUAGE plpgsql; *** 2474,2480 SELECT merge_db(1, 'david'); SELECT merge_db(1, 'dennis'); /programlisting ! /para /example /sect2 --- 2474,2483 SELECT merge_db(1, 'david'); SELECT merge_db(1, 'dennis'); /programlisting ! This example assumes the literalunique_violation/ error is caused by ! the commandINSERT/, and not by an commandINSERT/ trigger function ! on the table. Also, this example only works in the default Read ! Committed transaction mode. /para /example /sect2 -- 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] contrib loose ends: 9.0 to 9.1 incompatibilities
On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: So, after some testing, attached are two different fixed-up versions of pg_tgrm's update-from-unpackaged script. The first one leaves the parameter lists of some GIN support functions different from what they would be if you installed pg_trgrm fresh in 9.1. The second one fixes the parameter lists too, by means of really ugly direct UPDATEs on pg_proc. I'm unsure which one to apply --- any opinions? It's worth noting that both versions still leave the pg_trgm opclasses a bit different from a fresh install, because the added operators are loose in the opfamily rather than being bound into the opclass. This hasn't got any real functional effect, but if you were feeling paranoid you could worry about whether the two different states could cause problems for future versions of the update script. As far as I can see, the only thing we could realistically do about this with the tools at hand is to change pg_trgm's install script so that it also creates the new-in-9.1 entries loose. That seems a tad ugly, but depending on where you stand on the paranoia scale you might think it's a good idea. There is definitely no point in that refinement unless we update the function parameter lists, though. Comments? I think we should try to make the state match as closely as possible, no matter how you got there. Otherwise, I think we're storing up a host of future pain for ourselves. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove upsert example from docs
On 2011-02-17 8:37 PM +0200, Bruce Momjian wrote: Marko Tiikkaja wrote: The problem with the safe way is that it's not safe if called in a transaction with isolation level set to SERIALIZABLE. Good analysis. Documentation patch attached and applied. The safe way I was referring to above was the LOCK TABLE method, not the one described in the documentation, so the remark about READ COMMITTED in the patch should be removed. The first part looks fine though. Regards, Marko Tiikkaja -- 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] contrib loose ends: 9.0 to 9.1 incompatibilities
Robert Haas robertmh...@gmail.com writes: On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: It's worth noting that both versions still leave the pg_trgm opclasses a bit different from a fresh install, because the added operators are loose in the opfamily rather than being bound into the opclass. This hasn't got any real functional effect, but if you were feeling paranoid you could worry about whether the two different states could cause problems for future versions of the update script. As far as I can see, the only thing we could realistically do about this with the tools at hand is to change pg_trgm's install script so that it also creates the new-in-9.1 entries loose. That seems a tad ugly, but depending on where you stand on the paranoia scale you might think it's a good idea. There is definitely no point in that refinement unless we update the function parameter lists, though. Comments? I think we should try to make the state match as closely as possible, no matter how you got there. Otherwise, I think we're storing up a host of future pain for ourselves. Well, if you're willing to hold your nose for the UPDATE pg_proc hack, we can make it so. 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] COPY ENCODING revisited
On Wed, Feb 16, 2011 at 10:45 PM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: COPY ENCODING patch was returned with feedback, https://commitfest.postgresql.org/action/patch_view?id=501 but we still need it for file_fdw. Using client_encoding at runtime is reasonable for one-time COPY command, but logically nonsense for persistent file_fdw tables. Base on the latest patch, http://archives.postgresql.org/pgsql-hackers/2011-01/msg02903.php I added pg_any_to_server() and pg_server_to_any() functions instead of exposing FmgrInfo in pg_wchar.h. They are same as pg_client_to_server() and pg_server_to_client(), but accept any encoding. They use cached conversion procs only if the specified encoding matches the client encoding. According to Harada's research, http://archives.postgresql.org/pgsql-hackers/2011-01/msg02397.php non-cached conversions are slower than cached ones. This version provides the same performance before when file and client encoding are same, but would be a bit slower on other cases. We could improve the performance in future versions, for example, caching each used conversion proc in pg_do_pg_do_encoding_conversion(). file_fdw will support ENCODING option. Also, if not specified it might have to store the client_encoding at CREATE FOREIGN TABLE. Even if we use a different client_encoding at SELECT, the encoding at definition is used. ENCODING 'quoted name' issue is also fixed; it always requires quoted names. I think we only accept non-quoted text as identifier names. Unquoted text should be treated as double quoted, but encoding names are not identifiers. I am not qualified to fully review this patch because I'm not all that familiar with the encoding stuff, but it looks reasonably sensible on a quick read-through. I am supportive of making a change in this area even at this late date, because it seems to me that if we're not going to change this then we're pretty much giving up on having a usable file_fdw in 9.1. And since postgresql_fdw isn't in very good shape either, that would mean we may as well give up on SQL/MED. We might have to do that anyway, but I don't think we should do it just because of this issue, if there's a reasonable fix. I don't think the fact that the performance bites is a reason not to do this. As you say, that can always be improved in the future. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] contrib loose ends: 9.0 to 9.1 incompatibilities
On Thu, Feb 17, 2011 at 1:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: It's worth noting that both versions still leave the pg_trgm opclasses a bit different from a fresh install, because the added operators are loose in the opfamily rather than being bound into the opclass. This hasn't got any real functional effect, but if you were feeling paranoid you could worry about whether the two different states could cause problems for future versions of the update script. As far as I can see, the only thing we could realistically do about this with the tools at hand is to change pg_trgm's install script so that it also creates the new-in-9.1 entries loose. That seems a tad ugly, but depending on where you stand on the paranoia scale you might think it's a good idea. There is definitely no point in that refinement unless we update the function parameter lists, though. Comments? I think we should try to make the state match as closely as possible, no matter how you got there. Otherwise, I think we're storing up a host of future pain for ourselves. Well, if you're willing to hold your nose for the UPDATE pg_proc hack, we can make it so. Yes, I think that's better than leaving things in a different state. It's not my first choice, but it's better than the alternative. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] COPY ENCODING revisited
2011/2/17 Itagaki Takahiro itagaki.takah...@gmail.com: Base on the latest patch, http://archives.postgresql.org/pgsql-hackers/2011-01/msg02903.php I added pg_any_to_server() and pg_server_to_any() functions instead of exposing FmgrInfo in pg_wchar.h. They are same as pg_client_to_server() and pg_server_to_client(), but accept any encoding. They use cached conversion procs only if the specified encoding matches the client encoding. It sounds good to me since the approach doesn't make any overhead to the current behavior, although additional ENCODING option usage gets a bit slower. Nothing lost. FWIW, I finally found the good example to cache miscellaneous data in file local, namely regexp.c. It allocates compiled regular expressions up to 32 by using malloc(). We need only 4 or so for encoding conversion cache, in which cache search doesn't seem like overhead. I don't have time to make it as patch, but in a few days I'll try it. Regards, -- Hitoshi Harada -- 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
On 02/17/2011 12:54 PM, Kevin Grittner wrote: Andrew Dunstanand...@dunslane.net wrote: Ugh. Isn't there some sort of pragma or similar we can use to shut it up? If that fails, maybe use some function like the below? That would also have the advantage of not relying on assumptions beyond the documented API, which I tend to feel good about no matter how sure I am that the implementation details upon which I'm relying won't change. No claims that this is good final form, especially when it comes to using ssize_t, but just trying to get across the general idea: void write_completely_ignore_errors(int filedes, const void *buffer, size_t size) { size_t t = 0; while (t size) { ssize_t n = write(filedes, buffer, size - t); if (n= 0) break; t += n; } } In a very modern gcc, where we seem to be getting the errors from, maybe |#pragma GCC diagnostic push |#pragma GCC diagnostic ignored -Wunused-result write( ...); #pragma GCC diagnostic pop would work. See http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas 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