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.
"Kevin Grittner" writes: > Tom Lane 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
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 http://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: > > 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 http://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
* 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Tom Lane 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
Stephen Frost 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] ALTER EXTENSION UPGRADE, v3
Peter Eisentraut 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
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas 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] 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
Robert Haas 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
On Wed, Feb 16, 2011 at 9:52 PM, Stephen Frost 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] 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
On Thu, 2011-02-17 at 10:09 -0500, Tom Lane wrote: > Simon Riggs 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: > 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] 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 http://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
Dave Page wrote: > On Thu, Feb 17, 2011 at 11:45 AM, Magnus Hagander wrote: > > On Thu, Feb 17, 2011 at 11:49, Dave Page 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 http://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] btree_gist (was: CommitFest progress - or lack thereof)
Robert Haas writes: > 2011/2/17 Oleg Bartunov : >> 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Simon Riggs 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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
On Thu, Feb 17, 2011 at 9:50 AM, Simon Riggs wrote: > On Thu, 2011-02-17 at 14:37 +, Peter Geoghegan wrote: >> On 17 February 2011 08:30, Simon Riggs 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.
On Thu, 2011-02-17 at 14:37 +, Peter Geoghegan wrote: > On 17 February 2011 08:30, Simon Riggs 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 17 February 2011 08:30, Simon Riggs 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] 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] 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] Fix for Index Advisor related hooks
On Wed, Feb 16, 2011 at 6:37 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > On Wed, Feb 16, 2011 at 10:25 AM, Tom Lane 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
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] 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
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 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 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] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 11:45 AM, Magnus Hagander wrote: > On Thu, Feb 17, 2011 at 11:49, Dave Page 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] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 11:49, Dave Page wrote:
> On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander wrote:
>> On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake
>> 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] 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 3:39 AM, Stephen Frost 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] sepgsql contrib module
On Thu, Feb 17, 2011 at 3:56 AM, Kohei Kaigai 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] 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] btree_gist (was: CommitFest progress - or lack thereof)
2011/2/17 Oleg Bartunov : > 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] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 4:50 AM, Jason Earl 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] 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 10:36 AM, Magnus Hagander wrote:
> On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake 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] Debian readline/libedit breakage
On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake 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] tsearch Parser Hacking
On 16 Feb 2011, at 23:22, "David E. Wheeler" 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] 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] Fwd: [JDBC] Weird issues when reading UDT from stored function
2011/2/17 rsmogura : > 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 : >>> >>> 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
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
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
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
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 : 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
2011/2/17 Florian Pflug : > 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
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
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
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 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] 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 wrote: On Sat, Feb 12, 2011 at 7:47 AM, Stephen Frost 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] Usability tweaks for extension commands
Tom Lane 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] Fix corner case for binary upgrade: extension functions in pg_catalog.
Tom Lane writes: > Dimitri Fontaine writes: >> Tom Lane 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
[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
