Re: [HACKERS] ALTER EXTENSION UPGRADE, v3
Tom Lane t...@sss.pgh.pa.us writes: My feeling about this is that we should recommend that version identifiers be limited to ASCII letters, digits, dots, and underscore, but assume that extension authors are adults and can grasp the risks of using other characters. We should not be in the business of trying to force authors to write portable code whether they want to or not. That's a reasonable view point too, and it's less work this way. I would have liked to be able to sort versions in SQL as a gain on this work, but well… I think we've now converged on the agreement that we don't need to use anything but equality checks. So it doesn't matter how the author thinks the strings sort --- the upgrade scripts he provides define what can follow what, and that's all we need to know. Check. Well, you could look to see if there is a script that can update your current version to something else. The existing pg_available_extensions view needs to be rethought a bit, probably, but I'm not sure how. Maybe a SRF would do better here, returning the three columns step, from and to. The step is the order in which to read the rows. There would be some windowing or groups in the result set, but that should be ok. I can already hear people wanting version aliases instead. We could support e.g. 4 or 5 aliases like 'stable', 'support', 'alpha', 'beta' and maybe 'experimental'. Then rather than defining current_version authors would define any set of those keywords here, and CREATE EXTENSION and ALTER EXTENSION would by default only care for resp. 'stable' and 'support'. Hmm. That might be worth doing, but let's leave it for later when we find out how much demand there really is. It does strike me that what we ought to call the default-version parameter is just default, since that would fit in reasonably well with such an extension later. We could go as far as not requiring anything but considering any unknown parameter as a version alias, or setup a GUC placeholder so that the control file parsing is able to read version.defaut = '1.0' and others. Then we would just document what the default aliases are used by the commands CREATE EXTENSION and ALTER EXTENSION UPDATE TO. The big advantage of doing so is that it's then easy for extension authors to manage EOL. ALTER EXTENSION foo UPDATE; ERROR: there's no 'support' version available from version 1.2.3 Then you have to write ALTER EXTENSION foo UPDATE TO '2.0' or even UPDATE TO 'stable', and you realise it's a major upgrade, so you need to recheck the extension release notes etc. 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] ALTER EXTENSION UPGRADE, v3
Tom Lane t...@sss.pgh.pa.us writes: Actually, I was having second thoughts about that while at dinner. What is the value of separating the bootstrap-an-extension-from-old-objects operation into two steps? It's certainly not convenient for users, and I don't see that the intermediate state with an empty extension has any redeeming social value for developers either. (If you need such a thing, just make an empty creation script.) The only reason for doing it this way is that we used to only support 1 available version of an extension at a time, and the commands didn't know zip about versions. Now that you're putting VERSION support into CREATE and ALTER EXTENSION commands, I agree that a two steps process here is to reconsider. So: let's forget the concept of a special null version altogether, at least from the user's-eye viewpoint. Instead, the way to bootstrap from loose objects is something like CREATE EXTENSION foo [ VERSION '1.0' ] [ FROM OLD ] When you specify FROM OLD, this runs foo--1.0.sql instead of foo-1.0.sql as it normally would. As before, that script contains ALTER EXTENSION ADD commands instead of CREATE commands. Sounds good. The problem we have here, it seems to me, is that we don't know what was the previous version of the extension. It certainly existed, it's just that PostgreSQL does not know about it. That's what drove me to think about it as a 'FROM NULL' update. If you buy into the version alias feature, then what we can do here is supporting any alias as the FROM argument. The control file would then associate version.whatever = 0.9 and then the file is foo-0.9-1.0.sql in your example. The mechanism would be about the exact thing you described, but with just a useful indirection in between so that you type: CREATE EXTENSION foo VERSION stable FROM whatever; If we require those version aliases to be accepted as GUC names I guess we can bypass quoting them at the SQL level too, right? 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] ALTER EXTENSION UPGRADE, v3
Tom Lane t...@sss.pgh.pa.us writes: First off, I don't much care for the name CREATE WRAPPER EXTENSION. WRAPPER is a misnomer in this case --- it's not wrapping anything. I think Dimitri stated that he chose WRAPPER just because it was an already existing keyword, but that isn't much of an excuse. Let's get rid of the two-stages idea now that we have proper VERSION support in the commands, as seen in another email. Second, I don't like anything about the term null version for the case of bootstrapping from an old-style contrib module. Null implies unknown, which isn't what we've got here --- the upgrade script is going Yes it's what we have, the way I see it at least. The version number certainly exists, it's just that PostgreSQL had no way to know about it until now. Certainly that concept can be called unknown… One minor objection to this idea is that foo--1.0.sql looks more like a typo than anything else. We could alternatively decide that the special reserved version name is '0', so that bootstrap script names look like foo-0-1.0.sql. But if you don't want to have any built-in assumptions about what version names mean, you might not like that idea. I hope you will like the version aliases proposal I've been making in other emails, just saying it again as a loose cross-reference :) Third, I'm also not thrilled with the syntax ALTER EXTENSION foo UPGRADE. UPGRADE isn't an existing keyword (note that VERSION is). Fair enough. And I don't see any strong reason to assume that the version change is an upgrade. Authors might well choose to support sidegrades or downgrades, especially with experimental modules. I suggest either ALTER EXTENSION foo UPDATE [ TO 'version' ] ALTER EXTENSION foo VERSION [ 'version' ] the main excuse for the latter being that it's closer to the comparable syntax in CREATE EXTENSION. I somehow would prefer a mix of those two proposals: ALTER EXTENSION foo TO VERSION 'version'; ALTER EXTENSION foo TO VERSION alias; 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] pl/python custom exceptions for SPI
On 10/02/11 22:26, Steve Singer wrote: On 11-02-10 03:13 PM, Jan Urbański wrote: On 10/02/11 20:24, Peter Eisentraut wrote: Here is the rest of my review. Thanks! Ideally char * members of ExceptionMap would be const, but since many versions of python take a non-const value to PyErr_NewException that won't work :( Yeah, I got discards qualifier warnings when I tried to declare it as const :( After you search the for an exception in the hash you have: /* We really should find it, but just in case have a fallback */ Assert(entry != NULL); exc = entry ? entry-exc : PLy_exc_spi_error; I'm not sure the assert is needed here. Just falling back to the exception type seems reasonable and more desirable than an assert if showhow a new exception gets missed from the list. I don't feel that strongly on this. Maybe the comment doesn't explain this enough. My intention was that in regular builds you have a fallback and if you're missing an entry in the exceptions hash, you just get SPIError. But in assert-enabled builds you get an error, so you can detect it and fix the exceptions hash. line 3575: PLy_elog(ERROR, Failed to add the spiexceptions module); Failed should be failed Gah, I'll never learn. Will fix. Other than that the patch looks fine to me. Thanks, I'll have the docs ready by today (and I should've have them by yesterday :/). Jan -- 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] Sorting. When?
Thank you all for your replies. So, is there any precise way to discover when sorting is invoked? Thanks. Regards. Fava Il 11/02/2011 01:17, Robert Haas ha scritto: On Thu, Feb 10, 2011 at 6:21 PM, Nicolas Barbier nicolas.barb...@gmail.com wrote: 2011/2/10 mac_man2...@yahoo.itmac_man2...@yahoo.it: Which operations invoke the sorting algorithms implemented in the sorting module (tuplesort.c) ? Of course, one of those operations invoking sorting is the ORDER BY clause and the DISTINCT too. Moreover, the Merge Join should be implemented invoking sorting. Is there any other operation invoking sorting? AFAIK, all set operators except for UNION ALL. (I am probably missing a whole boatload of other things.) Merge joins don't necessarily involve a sort - you could do a merge over a pair of index scans, for example. Set operations can be implemented using hashing or sorting, too. -- 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 02/11/2011 05:05 AM, Tom Lane wrote: Actually, I was having second thoughts about that while at dinner. What is the value of separating the bootstrap-an-extension-from-old-objects operation into two steps? It's certainly not convenient for users, and I don't see that the intermediate state with an empty extension has any redeeming social value for developers either. (If you need such a thing, just make an empty creation script.) So: let's forget the concept of a special null version altogether, at least from the user's-eye viewpoint. Instead, the way to bootstrap from loose objects is something like CREATE EXTENSION foo [ VERSION '1.0' ] [ FROM OLD ] The above command assumes there is only one unpackaged version from which users might update from. Is that what is wanted? I am wondering if FROM OLD should be FROM OLD VERSION version (or better: FROM UNPACKAGED VERSION version). This would also solve how to name the old version(s). Author decides. - Anssi -- 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] Sorting. When?
[ Please don't top-post. URL:http://en.wikipedia.org/wiki/Posting_style ] 2011/2/11 mac_man2...@yahoo.it mac_man2...@yahoo.it: So, is there any precise way to discover when sorting is invoked? EXPLAIN shows how a query would be executed; explicit sorts should be mostly obvious. URL:http://www.postgresql.org/docs/9.0/static/sql-explain.html Nicolas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] spam (http://wiki.openssi.org/go/PostgreSQL_on_OpenSSI_enabled_Knoppix)
I just checked subj. and wondering what does it means and how many spam we may have on wiki ? PostgreSQL on OpenSSI enabled Knoppix From OpenSSI Jump to: navigation, search Acai Berry - The Best Protection For the economy today that are getting down its very important that you can have such protection and much more on this to put your health as good as always like taking a supplements like acai berry. Having this Acai Berry as one of your supplements in life you have such protection and you can gain control of your body to have such healthy lifestyle. It because fruit berry is one of the most effective way to have protection from the risk of arthritis, diabetes and other illness. Another thing you can get with this Acai berries is that it nourishes also the skin and hair to provide you such younger looking that you never experience before. And for the best part of this berry is that it improve blood circulation and to let you have a stronger immune system for you to enjoy with. Its very important now a days that people should take priorities with their health like maintaining like acai berry supplements because it can maintain your health in good condition as always. Not like other people that do not take even for Acai berries they suffer such illness and problem financially. With this berry you are not just protecting your health but as well your life in deed. Retrieved from http://wiki.openssi.org/go/PostgreSQL_on_OpenSSI_enabled_Knoppix; 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] spam (http://wiki.openssi.org/go/PostgreSQL_on_OpenSSI_enabled_Knoppix)
On Fri, Feb 11, 2011 at 7:14 AM, Oleg Bartunov o...@sai.msu.su wrote: I just checked subj. and wondering what does it means and how many spam we may have on wiki ? Hmm, that's not our wiki, it's on www.openssi.org. But I hit the undo link for them. -- 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] spam (http://wiki.openssi.org/go/PostgreSQL_on_OpenSSI_enabled_Knoppix)
I think that Acai berry supplements are used as part of various pyramid schemes. -- 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] ALTER EXTENSION UPGRADE, v3
On Fri, Feb 11, 2011 at 12:15 AM, Tom Lane t...@sss.pgh.pa.us wrote: David E. Wheeler da...@kineticode.com writes: On Feb 10, 2011, at 7:05 PM, Tom Lane wrote: (I'm not wedded to the phrase FROM OLD in particular, but it does reuse already existing keywords. Also, maybe it'd be better to reserve a version string such as old or bootstrap, so that the bootstrap script could be called something more legible like foo-bootstrap-1.0.sql.) Well, it's not really a bootstrap, is it? FROM OLD is okay, though not great. FROM BEFORE would be better. Or IMPLICIT? (It was implicitly an extension before.) Or, hey, FROM NOTHING! :-) Hmm, you're right. The word bootstrap implies that we're starting from nothing, which is exactly what we're *not* doing (starting from nothing is the easy clean install case). By the same token, FROM NOTHING isn't the right phrase either. An accurate description would be something like FROM UNPACKAGED OBJECTS, but I'm not seriously proposing that ... Well, you're bootstrapping the extension mechanism. Other ideas anyone? I still think you might be over-designing this. Upgrading from the pre-extension world doesn't need to be elegant; it just has to work. And you can do that yourself, with the proposed infrastructure: http://archives.postgresql.org/pgsql-hackers/2011-02/msg00911.php -- 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] [PERFORM] pgbench to the MAXINT
Greg, * Tom Lane (t...@sss.pgh.pa.us) wrote: Greg Smith g...@2ndquadrant.com writes: Poking around a bit more, I just discovered another possible approach is to use erand48 instead of rand in pgbench, which is either provided by the OS or emulated in src/port/erand48.c That's way more resolution than needed here, given that 2^48 pgbench accounts would be a scale of 2.8M, which makes for a database of about 42 petabytes. I think that might be a good idea --- it'd reduce the cross-platform variability of the results quite a bit, I suspect. random() is not to be trusted everywhere, but I think erand48 is pretty much the same wherever it exists at all (and src/port/ provides it elsewhere). Works for me. Greg, will you be able to work on this change? If not, I might be able to. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Debian readline/libedit breakage
On Thu, Feb 10, 2011 at 06:04:46PM -0500, Tom Lane wrote: Less narrow-minded interpretation of GPL requirements, perhaps. (And yes, we have real lawyers on staff considering these issues.) Is their opinion public/can be made public? This might possibly lead to a re-evaluation of the situation by Debian. If Debian want to shoot themselves in the foot like that, we can't stop them BTW, that change has been merged into Ubuntu and will be (as of now) in the next Ubuntu release. Michael -- 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
Robert Haas robertmh...@gmail.com writes: I still think you might be over-designing this. Upgrading from the pre-extension world doesn't need to be elegant; it just has to work. Allow me to disagree here. The main use case is not supporting users that upgrade with extensions to 9.1, but to allow people working on their own applications to some day realise they could as well package their PL code into a set of extensions. Please check my version aliases proposal and how it fits in there. -- 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] Range Types: -|- ops vs empty range
On Wed, February 9, 2011 09:35, Jeff Davis wrote: Updated patch. The operators and -|- have the following behavior with empty ranges: testdb=# select '-'::int4range range(200,300); ERROR: empty range testdb=# select '-'::int4range range(200,300); ERROR: empty range testdb=# select '-'::int4range -|- range(200,300); ERROR: empty range I'm not sure if that is deliberate behavior, but they seem almost bugs to me. Wouldn't it be better (and more practical) if these would return false (or perhaps NULL, for 'unknown') ? (the same goes for all the other range types, btw.) Erik Rijkers -- 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 Fri, Feb 11, 2011 at 9:00 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Robert Haas robertmh...@gmail.com writes: I still think you might be over-designing this. Upgrading from the pre-extension world doesn't need to be elegant; it just has to work. Allow me to disagree here. The main use case is not supporting users that upgrade with extensions to 9.1, but to allow people working on their own applications to some day realise they could as well package their PL code into a set of extensions. Sure, but we're talking about adding core code to accomplish two things: 1. Avoid the need for packagers to ship one empty file. 2. Possibly, allow the operation to be completed in one command instead of two. This is not exactly cutting anyone off at the kneecaps. -- 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) wrote: I don't think it's entirely stupid to worry about this completely screwing up the output of SHOW ALL on people using 80-character terminal windows. I haven't checked, but if it renders the output totally unreadable then I think we should try to find an alternative that doesn't. Alright, so I looked into this a bit and have a couple of comments: show all; output, at least on my test rig, is *already* well over 80-characters wide. The longest GUC is max_predicate_locks_per_transaction, which forces the first column to be 38 columns. We then have some rather long descriptions (which are only shown on show all, no clue why that is..), the longest being Sets whether XML data in implicit parsing and serialization operations is to be considered as documents or content fragments. (for xmloption). Now, it's true that the longest default *setting* w/ this patch is the list of CSV fields, but it's not like 'show all;' really works that well on an 80-character terminal today. The second longest setting, on my system, is the path to postgresql.conf: /data/sfrost/pgsql/test/data/postgresql.conf That, plus the length of max_predicate_locks_per_transaction, would make 'show all;' go beyond 80 characters even if we took out the description (but we don't currently support that..). This new option *would* make a query against an individual 'show name;' return, in the default configuration, a value longer than 80-characters, but we're just talking 1 row being returned there. My feeling is that this could be improved by supporting multi-line configuration settings, and then changing the longer descriptions to be multi-line, but that still wouldn't get us down to 80-characters due to the combination of max_predicate_locks_per_transaction and config_file. Renaming a configuration option isn't exactly a trivial thing to do either. :/ One thing that would be nice, but probably non-trivial, would be to allow show all; to be a subselect, so you could do things like, I dunno, pull the max length of certain columns. :) We could also have a 'show all;' which just returns the name and setting and then a 'show all verbose;' for including the description, or a 'show verbose name;' for getting all three fields when looking at a specific variable. All-in-all, I think we're past the point of being able to make show all; fit completely on an 80-character terminal, even in \x mode. I'd be willing to work on the multi-line stuff for 9.2, if people are really interested in it, but I don't think not having that should be a show-stopper for this patch, and I think that would be more likely to break client applications than this change.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] ALTER EXTENSION UPGRADE, v3
Robert Haas robertmh...@gmail.com writes: On Fri, Feb 11, 2011 at 9:00 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Robert Haas robertmh...@gmail.com writes: I still think you might be over-designing this. Upgrading from the pre-extension world doesn't need to be elegant; it just has to work. Allow me to disagree here. Sure, but we're talking about adding core code to accomplish two things: 1. Avoid the need for packagers to ship one empty file. 2. Possibly, allow the operation to be completed in one command instead of two. The empty file might not be a big deal, but I think that the user experience *is* a big deal. For the vast majority of users, dealing with an upgrade for some contrib module they are already using will be their first experience with the extension mechanism. If it's awkward or requires them to think about strange concepts like null versions, it's going to leave a bad taste in their mouths. Furthermore, I confidently predict that some people will screw it up by issuing only the first CREATE and not the second ALTER, leaving them with a database that still works but not in the intended fashion; from which we will get bug reports, perhaps years later. I agree it's a bit annoying to expend effort on something that will have only a one-shot use in any one installation, but to my mind this is an important fit and finish issue. For analogy, some might think that all the effort we spend on message translatability is overkill, but I think it contributes to a good user experience. 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 TYPE 2: skip already-provable no-work rewrites
On Thu, Jan 27, 2011 at 2:48 PM, Noah Misch n...@leadboat.com wrote: On Wed, Jan 26, 2011 at 07:31:40AM -0500, Robert Haas wrote: I'd also suggest that this big if-block you changed to a case statement could just as well stay as an if-block. There are only three cases, and we want to avoid rearranging things more than necessary. It complicates both review and back-patching to no good end. Okay. I've also left out the large reindent in ATRewriteTable for now. Easy to re-add it later if desired. I think you should collect up what's left of ALTER TABLE 0 and the stuff on this thread, rebase it, and submit it as a single patch on this thread that applies directly against the master branch. We may decide to split it back up again in some other way, but I think the current division isn't actually buying us much. Done as attached. This preserves compatibility with our current handling of composite type dependencies. The rest you've seen before. OK, I finally got back to this. Sorry for the delay. I still feel that it's possible to accomplish the same goal with less complexity. See what you think of the attached. Upon examination, it appeared to me that trying to make the AlteredTableInfo contain an enum indicating whether we were doing a scan, a rewrite, or nothing was requiring more code change than I could really justify. What I ended up doing is replacing the 'bool new_changedoids' member with a 'bool rewrite' member. I'm pretty sure this is safe. The only reason we ever tested the new_changeoids member was to see whether we needed to do a rewrite; it wasn't used for anything else. The new member gets set either when we need to do a rewrite, or when a column type changes in a fashion that requires a rewrite. It's pretty easy to verify that this doesn't result in any behavior change, except for one corner case: currently, if you add or remove OIDs to/from a table and in the same ALTER TABLE command add a constraint that involves creating an index, such as a primary key, the new primary key index will get built, thrown away, and rebuilt a second time. With this change, we just build it once, which seems like an improvement, even though the case is vanishingly unlikely to ever happen in practice. I also have to say that after playing with a little bit, I find the new debugging messages you added to be quite invaluable for understanding what's really going on. The old output told you basically nothing useful, even if you cranked it all the way up to DEBUG3. This is much better. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company alter-type-2-rmh.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add support for logging the current role
Stephen Frost sfr...@snowman.net wrote: That, plus the length of max_predicate_locks_per_transaction, would make 'show all;' go beyond 80 characters even if we took out the description Should we abbreviate something there? max_pred_locks_per_tran, maybe? -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] multiset patch review
On Fri, Feb 4, 2011 at 9:11 PM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: On Sat, Feb 5, 2011 at 04:24, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: In math class, maybe. But in programming, no. Multiset is a datatype. Array is a different datatype. There is no reason why we need to clutter our parser with extra keywords to support a non-standard feature extension. My understanding is that we will have to have those functions defined and user visible, and that we benefit from function overloading which is not in the standard. So there's no reason not to provide those function for arrays already, then extend to full multiset support. Given PostgreSQL overloading, yes, arrays are multisets as far as defining those standard compliant APIs is concerned. AFAIUI. Yes, I'd like to use overloading. Choosing arbitrary names increases learning costs for users. Right, but making the parser slower has a cost, too. ScanKeywordLookup() is already a hotspot in some workloads, and there's overhead buried in the bison parser, too. I think it's a big mistake to get into the business of adding keywords just so we can provide an alternative syntax to call a function. Many people who use these functions will never even have heard of the MULTISET stuff that is part of the spec, and even those that have can figure out our alternatives by spending five minutes with the documentation. I find it really difficult to accept that it is worth slowing down parsing for the 95% of users who are not going to use these functions to provide a slightly nicer API for the ones that do. -- 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
On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Stephen Frost sfr...@snowman.net wrote: That, plus the length of max_predicate_locks_per_transaction, would make 'show all;' go beyond 80 characters even if we took out the description Should we abbreviate something there? max_pred_locks_per_tran, maybe? If we're going to abbreviate transaction, I'd vote for txn over tran, but I think Stephen's point that this is already a lost cause may have some validity. Not sure what other people think. -- 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] ALTER EXTENSION UPGRADE, v3
=?ISO-8859-1?Q?Anssi_K=E4=E4ri=E4inen?= anssi.kaariai...@thl.fi writes: The above command assumes there is only one unpackaged version from which users might update from. Is that what is wanted? I am wondering if FROM OLD should be FROM OLD VERSION version (or better: FROM UNPACKAGED VERSION version). This would also solve how to name the old version(s). Author decides. Yeah, that's an interesting point. I don't think that there are any contrib modules for which we'd bother with such a thing, but it's easily possible that PostGIS or other third parties would be interested in supporting direct upgrades from older versions of their modules. I did actually have a scheme in mind whereby somebody could do that if they had to given my proposal of yesterday, but I won't bore you with the details because it was a crock. Thinking about the problem this morning, I came to the same solution you did, although I was thinking of a slightly more compact syntax: CREATE EXTENSION foo [ VERSION targetversion ] [ FROM oldversion ] The presence of FROM causes us to run foo-oldversion-targetversion.sql instead of foo-targetversion.sql. As before, that script would consist mostly of ALTER EXTENSION ADD rather than CREATE commands. What this means is we aren't hard-wiring any specific name for pre extension versions, and we aren't restricting the author to support updating from only one old version. The main risk factor I can see here is that users might give the wrong old version parameter, causing the system to try to run a script that was meant for updating some post-extensioning version instead of pre-extensioning (ie, CREATE EXTENSION foo FROM '1.0' when the right thing would have been CREATE EXTENSION foo FROM 'old'). I think however that we can live with that risk, on two grounds: 1. If you pick the wrong FROM version, the upgrade script will almost certainly fail, because the objects won't exist or won't be in the state it expects (ie, not already members of the extension). 2. The main use for this feature will be early in the lifespan of extensions, when there aren't going to be many post-extension upgrade scripts around to pose a risk of confusion. By the time there's really much risk of people making this mistake, it won't matter anymore. 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] REVIEW: Determining client_encoding from client locale
On Tue, Feb 8, 2011 at 5:05 AM, Ibrar Ahmed ibrar.ah...@gmail.com wrote: Stephen Frost! I have modified the code to use ADD_STARTUP_OPTION instead of writing code again. And tried the patch on Windows and Linux and it works for me. Does this need more review, or should it be marked Ready for Committer? -- 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] pl/python custom datatype parsers
On Sun, Feb 6, 2011 at 1:01 PM, Jan Urbański wulc...@wulczer.org wrote: That's it for now. It is an exciting feature and plpython will be the first language to think of when you're building object database if this feature is in. The design here will affect following pl/perl and other so it is important enough to discuss. Yes, I ended up writing this patch as a PoC of how you can integrate procedural languages with arbitrary addon modules, so it would be good to have a discussion about the general mechanisms. I'm aware that this discussion, and subsequently this patch, might be punted to 9.2 (although that would be a shame). It's not clear to me from this discussion whether this patch (a) now works and has consensus, and should be committed, (b) still needs more discussion, but hopes to make it into 9.1, or (c) is now 9.2 material. Can someone please clarify? -- 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] REVIEW: Determining client_encoding from client locale
* Robert Haas (robertmh...@gmail.com) wrote: On Tue, Feb 8, 2011 at 5:05 AM, Ibrar Ahmed ibrar.ah...@gmail.com wrote: And tried the patch on Windows and Linux and it works for me. Does this need more review, or should it be marked Ready for Committer? I think it can be marked ready for committer. Heikki addressed my questions, though I do think we may end up generalizing those states at some point later, if we ever end up with a similar argument to this one. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] pl/python tracebacks
On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański wulc...@wulczer.org wrote: On 06/02/11 20:12, Jan Urbański wrote: On 27/01/11 22:58, Jan Urbański wrote: On 23/12/10 14:56, Jan Urbański wrote: Here's a patch implementing traceback support for PL/Python mentioned in http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's an incremental patch on top of the plpython-refactor patch sent eariler. Updated to master. Updated to master again. Once more. Alex Hunsaker is listed as the reviewer for this patch, but I don't see a review posted. If this feature is still wanted for 9.1, can someone jump in here? -- 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] pl/python invalidate functions with composite arguments
On Thu, Feb 10, 2011 at 9:06 PM, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 9, 2011 at 02:09, Jan Urbański wulc...@wulczer.org wrote:
On 27/01/11 22:42, Jan Urbański wrote:
On 23/12/10 14:50, Jan Urbański wrote:
Here's a patch implementing properly invalidating functions that have
composite type arguments after the type changes, as mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Updated to master.
Again.
Looks good, it works as described, the code is clean and well
documented and it passes the added regression tests.
I took the liberty of looking at the other pls to see how they handled
this to find they don't cache them in the first place. For fun, I
hacked plpython to not cache to see if there was any performance
difference pre patch, post patch and in the non-cached cases. I
couldn't find any probably due to:
1) my simple test case (select
count(test_composite_table_input('(John, 100, (10))')) FROM
generate_series(1, 100);)
2) things being cached
3) cache invalidation having to do most of the work that the non
caching cache does. I think there is one or two more SearchSysCall's.
4) overhead from cassert
It seems a bit heavy handed to invalidate and remake the entire
plpython function whenever we hit this case. I think we could get away
with setting -is_rowtype = 2 in PLy_procedure_valid() instead. I
suppose it should be fairly rare case anyway so... *shrug*.
This last comment might make me think that we're looking for a new
version of this patch, but the comment on the CommitFest application
says looks good. So I'm not sure whether this should be marked
Waiting on Author or Ready for Committer, but the current status of
Needs Review looks wrong.
--
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] pl/python custom datatype parsers
On 11/02/11 16:43, Robert Haas wrote: On Sun, Feb 6, 2011 at 1:01 PM, Jan Urbański wulc...@wulczer.org wrote: That's it for now. It is an exciting feature and plpython will be the first language to think of when you're building object database if this feature is in. The design here will affect following pl/perl and other so it is important enough to discuss. Yes, I ended up writing this patch as a PoC of how you can integrate procedural languages with arbitrary addon modules, so it would be good to have a discussion about the general mechanisms. I'm aware that this discussion, and subsequently this patch, might be punted to 9.2 (although that would be a shame). It's not clear to me from this discussion whether this patch (a) now works and has consensus, and should be committed, (b) still needs more discussion, but hopes to make it into 9.1, or (c) is now 9.2 material. I believe it's (b). But as we don't have time for that discussion that late in the release cycle, I think we need to consider it identical to (c). Cheers, Jan -- 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?
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: it seems that PredicateLockTupleRowVersionLink sometimes create a loop of targets (it founds an existing 'newtarget' whose nextVersionOfRow chain points to the 'oldtarget') and it later causes CheckTargetForConflictsIn loop forever. Is this a hypothetical risk based on looking at the code, or have you seen this actually happen? Either way, could you provide more details? (A reproducible test case would be ideal.) This being the newest part of the code, I'll grant that it is the most likely to have an unidentified bug; but given that the pointers are from one predicate lock target structure identified by a tuple ID to one identified by the tuple ID of the next version of the row, it isn't obvious to me how a cycle could develop. -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] multiset patch review
Robert Haas robertmh...@gmail.com writes: Right, but making the parser slower has a cost, too. ScanKeywordLookup() is already a hotspot in some workloads, and there's overhead buried in the bison parser, too. Yeah. Keep in mind that a bison parser fundamentally runs off a two-dimensional array: one axis is parser state and the other is token number. They have some tricks to compress the array a bit, but adding keywords contributes directly to a bigger array, which means slower parsing (more L1 cache misses). The parser's inner loop frequently shows up as a hotspot in profiles I do, and I think that has to be more about the amount of data it's touching than the cost of the loop per se. Adding unnecessary keywords is something to be avoided. 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] pl/python invalidate functions with composite arguments
On 11/02/11 16:47, Robert Haas wrote: On Thu, Feb 10, 2011 at 9:06 PM, Alex Hunsaker bada...@gmail.com wrote: On Wed, Feb 9, 2011 at 02:09, Jan Urbański wulc...@wulczer.org wrote: It seems a bit heavy handed to invalidate and remake the entire plpython function whenever we hit this case. I think we could get away with setting -is_rowtype = 2 in PLy_procedure_valid() instead. I suppose it should be fairly rare case anyway so... *shrug*. This last comment might make me think that we're looking for a new version of this patch, but the comment on the CommitFest application says looks good. So I'm not sure whether this should be marked Waiting on Author or Ready for Committer, but the current status of Needs Review looks wrong. I'm not planning on writing a new version of the patch. AIUI Alex said, that there's a possible optimization to be done, but the gain is so small that it doesn't matter. Jan -- 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] REVIEW: Determining client_encoding from client locale
On Fri, Feb 11, 2011 at 10:45 AM, Stephen Frost sfr...@snowman.net wrote: * Robert Haas (robertmh...@gmail.com) wrote: On Tue, Feb 8, 2011 at 5:05 AM, Ibrar Ahmed ibrar.ah...@gmail.com wrote: And tried the patch on Windows and Linux and it works for me. Does this need more review, or should it be marked Ready for Committer? I think it can be marked ready for committer. Heikki addressed my questions, though I do think we may end up generalizing those states at some point later, if we ever end up with a similar argument to this one. OK, done. -- 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) wrote: On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner Should we abbreviate something there? max_pred_locks_per_tran, maybe? If we're going to abbreviate transaction, I'd vote for txn over tran, but I think Stephen's point that this is already a lost cause may have some validity. Not sure what other people think. There's lots of other GUCs with transaction spelled out in them.. :/ Another option, which I don't like, would be to use 'default' by 'default', and build the list on the fly every time if that's what it is.. That would give no insight into what the list of fields is for someone though, they'd have to go back to the documentation to figure it out, and that sucks.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] pl/python invalidate functions with composite arguments
On Fri, Feb 11, 2011 at 10:51 AM, Jan Urbański wulc...@wulczer.org wrote: On 11/02/11 16:47, Robert Haas wrote: On Thu, Feb 10, 2011 at 9:06 PM, Alex Hunsaker bada...@gmail.com wrote: On Wed, Feb 9, 2011 at 02:09, Jan Urbański wulc...@wulczer.org wrote: It seems a bit heavy handed to invalidate and remake the entire plpython function whenever we hit this case. I think we could get away with setting -is_rowtype = 2 in PLy_procedure_valid() instead. I suppose it should be fairly rare case anyway so... *shrug*. This last comment might make me think that we're looking for a new version of this patch, but the comment on the CommitFest application says looks good. So I'm not sure whether this should be marked Waiting on Author or Ready for Committer, but the current status of Needs Review looks wrong. I'm not planning on writing a new version of the patch. AIUI Alex said, that there's a possible optimization to be done, but the gain is so small that it doesn't matter. OK, marked Ready for Committer. -- 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
On Fri, Feb 11, 2011 at 10:52 AM, Stephen Frost sfr...@snowman.net wrote: * Robert Haas (robertmh...@gmail.com) wrote: On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner Should we abbreviate something there? max_pred_locks_per_tran, maybe? If we're going to abbreviate transaction, I'd vote for txn over tran, but I think Stephen's point that this is already a lost cause may have some validity. Not sure what other people think. There's lots of other GUCs with transaction spelled out in them.. :/ Another option, which I don't like, would be to use 'default' by 'default', and build the list on the fly every time if that's what it is.. That would give no insight into what the list of fields is for someone though, they'd have to go back to the documentation to figure it out, and that sucks.. Yeah. The root cause of this problem is that the way psql handles tabular output with a few very wide rows stinks. -- 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] pl/python invalidate functions with composite arguments
On Fri, Feb 11, 2011 at 08:47, Robert Haas robertmh...@gmail.com wrote:
On Thu, Feb 10, 2011 at 9:06 PM, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 9, 2011 at 02:09, Jan Urbański wulc...@wulczer.org wrote:
On 27/01/11 22:42, Jan Urbański wrote:
On 23/12/10 14:50, Jan Urbański wrote:
Here's a patch implementing properly invalidating functions that have
composite type arguments after the type changes, as mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Updated to master.
Again.
Looks good, it works as described, the code is clean and well
documented and it passes the added regression tests.
I took the liberty of looking at the other pls to see how they handled
this to find they don't cache them in the first place. For fun, I
hacked plpython to not cache to see if there was any performance
difference pre patch, post patch and in the non-cached cases. I
couldn't find any probably due to:
1) my simple test case (select
count(test_composite_table_input('(John, 100, (10))')) FROM
generate_series(1, 100);)
2) things being cached
3) cache invalidation having to do most of the work that the non
caching cache does. I think there is one or two more SearchSysCall's.
4) overhead from cassert
It seems a bit heavy handed to invalidate and remake the entire
plpython function whenever we hit this case. I think we could get away
with setting -is_rowtype = 2 in PLy_procedure_valid() instead. I
suppose it should be fairly rare case anyway so... *shrug*.
This last comment might make me think that we're looking for a new
version of this patch, but the comment on the CommitFest application
says looks good. So I'm not sure whether this should be marked
Waiting on Author or Ready for Committer, but the current status of
Needs Review looks wrong.
Drat, Ive been found it. I just didn't want to make things to easy for you. :)
--
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] pl/python custom datatype parsers
On Fri, Feb 11, 2011 at 10:49 AM, Jan Urbański wulc...@wulczer.org wrote: On 11/02/11 16:43, Robert Haas wrote: On Sun, Feb 6, 2011 at 1:01 PM, Jan Urbański wulc...@wulczer.org wrote: That's it for now. It is an exciting feature and plpython will be the first language to think of when you're building object database if this feature is in. The design here will affect following pl/perl and other so it is important enough to discuss. Yes, I ended up writing this patch as a PoC of how you can integrate procedural languages with arbitrary addon modules, so it would be good to have a discussion about the general mechanisms. I'm aware that this discussion, and subsequently this patch, might be punted to 9.2 (although that would be a shame). It's not clear to me from this discussion whether this patch (a) now works and has consensus, and should be committed, (b) still needs more discussion, but hopes to make it into 9.1, or (c) is now 9.2 material. I believe it's (b). But as we don't have time for that discussion that late in the release cycle, I think we need to consider it identical to (c). OK, I'll mark it Returned with Feedback. -- 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) wrote: Yeah. The root cause of this problem is that the way psql handles tabular output with a few very wide rows stinks. True, but it would be kinda nice to support multi-line configuration variables. I still vote for that being not required to get this patch in, but it's certainly something we could do later. Of course, you do have to ask yourself what having \n's in log_line_prefix would mean in the config file.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SQL/MED - file_fdw
On Wed, Feb 9, 2011 at 2:03 AM, Noah Misch n...@leadboat.com wrote: From a functional and code structure perspective, I find this ready to commit. (I assume you'll drop the XXX: indent only comments on commit.) Kevin, did you want to do that performance testing you spoke of? OK, so is this Ready for Committer, or we're still working on it? -- 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] multiset patch review
On Sat, Feb 12, 2011 at 00:50, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Right, but making the parser slower has a cost, too. ScanKeywordLookup() is already a hotspot in some workloads, and there's overhead buried in the bison parser, too. Yeah. Keep in mind that a bison parser fundamentally runs off a two-dimensional array: one axis is parser state and the other is token number. They have some tricks to compress the array a bit, but adding keywords contributes directly to a bigger array, which means slower parsing (more L1 cache misses). The parser's inner loop frequently shows up as a hotspot in profiles I do, and I think that has to be more about the amount of data it's touching than the cost of the loop per se. Did you measure the actual cost in the real world? If we are using such a sensitive parser, it should be a problem even without the patch. Adding unnecessary keywords is something to be avoided. Our conclusion is we never support multiset syntax in the SQL standard, right? If we think they are unnecessary, we cannot support it. I will remove parser changes from the patch; it will add only a few array functions. Then, please let me know functions you don't want to include in the core, if any. I'll remove them at the same time. -- Itagaki Takahiro -- 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] pl/python explicit subtransactions
On 11-02-10 05:20 AM, Jan Urbański wrote: D'oh, I was thinking about whether it's safe to skip the internal subxact if you're in an implicit one and somehow I always convinced myself that since you eventually close the explicit one, it is. Obviously my testing wasn't enough :( Attaching an updated patch with improved docs incorporating Steve's fixes, and fixes tests for not statring the implicit subxact. That actually makes the patch a bit smaller ;) OTOH I had to remove the section from the docs that claimed performance improvement due to only starting the explicit subxact... This version of the patch looks fine to me and seems to work as expected. Cheers, Jan
Re: [HACKERS] ALTER EXTENSION UPGRADE, v3
Tom Lane t...@sss.pgh.pa.us writes: CREATE EXTENSION foo [ VERSION targetversion ] [ FROM oldversion ] I came to the same conclusion but added my version aliases idea in there so that it could maybe be easy for the user not to confuse things. I still think that free form version aliases and some defaults used by the core code is a very interesting feature to have, but I can see that it's not required for the feature to fully work. 1. If you pick the wrong FROM version, the upgrade script will almost certainly fail, because the objects won't exist or won't be in the state it expects (ie, not already members of the extension). Is there a test somewhere that when CREATE OR REPLACE FUNCTION runs from an extension's script at upgrade, the function must already be attached to the extension if it exists in the system? Ditto for views etc? 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] pl/python tracebacks
On Fri, Feb 11, 2011 at 08:45, Robert Haas robertmh...@gmail.com wrote: On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański wulc...@wulczer.org wrote: On 06/02/11 20:12, Jan Urbański wrote: On 27/01/11 22:58, Jan Urbański wrote: On 23/12/10 14:56, Jan Urbański wrote: Here's a patch implementing traceback support for PL/Python mentioned in http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's an incremental patch on top of the plpython-refactor patch sent eariler. Updated to master. Updated to master again. Once more. Alex Hunsaker is listed as the reviewer for this patch, but I don't see a review posted. If this feature is still wanted for 9.1, can someone jump in here? Goodness... I picked up this patch the day before yesterday because no-one was listed. That being said, if anyone else wants to beat me to the punch of reviewing this, have at it! The more eyes the merrier! I wish I could squeeze the lime of my time to find a few more hours -- 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
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote: On Mon, Feb 7, 2011 at 04:10, Stephen Frost sfr...@snowman.net wrote: Yeah, doesn't seem to work for me (missing '/bin/collateindex.pl', apparently..). You might need yum install openjade stylesheets or similar packages and re-configure. I've got openjade, etc, installed, but I'm on Debian and it doesn't appear to include that collateindex.pl anywhere.. For implementation, write_csvlog() has many following lines: if (curr_field != num_fields) appendStringInfoChar(buf, ','); It will be cleaner if we add first_col flag and move it out of the switch statement. Done. Other questions I raised before might be matters of preference. I'd like to here about them form third person. * name: log_csv_fields vs. csvlog_fields Done. * when to assign: PGC_POSTMASTER vs. PGC_SIGHUP I'm still in the PGC_POSTMASTER camp on this and I really think it's a more complicated change than just changing that value in the code, even if we all agreed it should be allowed on SIGHUP (which certainly isn't the case anyway..). In the end, if we really want that, we can always add it in the future. Updated patch attached, full git log below. Thanks, Stephen commit 6bd2b9f1d2bc3b166a3e5598ee590e25159c61a5 Author: Stephen Frost sfr...@snowman.net Date: Fri Feb 11 11:16:17 2011 -0500 Rename log_csv_fields GUC to csvlog_fields This patch renames the log_csv_fileds GUC to csvlog_fields, to better match the other csvlog_* options. Also cleaned up the CSV generation code a bit by moving the comma-adding code out of the switch() statement. commit a281ca611e6181339e92b488c815e0cb8c1298d2 Merge: d81 183d3cf Author: Stephen Frost sfr...@snowman.net Date: Fri Feb 11 08:37:27 2011 -0500 Merge branch 'master' of git://git.postgresql.org/git/postgresql into log_csv_options commit d81c425a4c320540769084ceeb7d23bc3662 Author: Stephen Frost sfr...@snowman.net Date: Sun Feb 6 14:02:05 2011 -0500 Change log_csv_options listing to a table This patch changes the listing of field options available to log_csv_options into a table, which will hopefully both look better and be clearer. commit f9851cdfaeb931f01c015f5651b72d16957c7114 Merge: 3e71e33 5ed45ac Author: Stephen Frost sfr...@snowman.net Date: Sun Feb 6 13:26:17 2011 -0500 Merge branch 'master' of git://git.postgresql.org/git/postgresql into log_csv_options commit 3e71e338a2b9352d730f59a989027e33d99bea50 Author: Stephen Frost sfr...@snowman.net Date: Fri Jan 28 22:44:33 2011 -0500 Cleanup log_csv_options patch Clean up of various function declarations to hopefully be correct and clean and matching PG conventions. Also move TopMemoryContext usage to later, since the local variables don't need to be in TopMemoryContext. Lastly, ensure that a comma is not produced after the last CSV field, and that one is produced if application_name is not the last field. Review by Itagaki Takahiro, thanks! commit 1825def11badd661d219fa4c516f06e0ad423443 Merge: ff249ae 847e8c7 Author: Stephen Frost sfr...@snowman.net Date: Wed Jan 19 06:50:03 2011 -0500 Merge branch 'master' of git://git.postgresql.org/git/postgresql into log_csv_options commit ff249aeac7216da623bf77840380d5e767f681fc Author: Stephen Frost sfr...@snowman.net Date: Wed Jan 19 00:26:52 2011 -0500 Add log_csv_fields GUC for CSV output curr_role This patch adds a new GUC called 'log_csv_fields'. This GUC allows the user to control the set of fields written to the CSV output as well as the order in which they are written. The default set of fields remains those that were included in 9.0, to avoid breaking existing user configurations. In passing, update 'user_name' for log_line_prefix and log_csv_fields to mean 'session user' (which could be reset by a superuser with set session authorization), and add a 'role_name' option (%U) to log_line_prefix and log_csv_fields, to allow users to log the current role (as set by SET ROLE- not impacted by SECURITY DEFINER functions). *** a/doc/src/sgml/config.sgml --- b/doc/src/sgml/config.sgml *** *** 3519,3525 local0.*/var/log/postgresql /row row entryliteral%u/literal/entry ! entryUser name/entry entryyes/entry /row row --- 3519,3538 /row row entryliteral%u/literal/entry ! entrySession user name, typically the user name which was used ! to authenticate to productnamePostgreSQL/productname with, ! but can be changed by a superuser, see commandSET SESSION ! AUTHORIZATION//entry ! entryyes/entry ! /row ! row ! entryliteral%U/literal/entry !
Re: [HACKERS] Add support for logging the current role
Robert Haas robertmh...@gmail.com writes: On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Should we abbreviate something there? max_pred_locks_per_tran, maybe? If we're going to abbreviate transaction, I'd vote for txn over tran, but I think Stephen's point that this is already a lost cause may have some validity. Not sure what other people think. Aren't we already using xact for that purpose in some user-visible places? But personally I'd be happy with max_pred_locks_per_transaction which gets the worst case down without being too obviously at variance with max_locks_per_transaction. 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] multiset patch review
On Fri, Feb 11, 2011 at 11:17 AM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: Did you measure the actual cost in the real world? If we are using such a sensitive parser, it should be a problem even without the patch. It *is* a problem without the patch! Adding unnecessary keywords is something to be avoided. Our conclusion is we never support multiset syntax in the SQL standard, right? If we think they are unnecessary, we cannot support it. No, my conclusion is that if we're not really doing what the standard says anyway, it's not worth the cost of the new keywords. Whether or not we'd be willing to pay the cost for an implementation that actually conformed with the standard is not something I believe we've decided. But it's not going to happen any time soon, because adding actual multiset types would bloat pg_type by another 50%, which is a cost I doubt that we will be willing to pay. I really hope someone will eventually fix things so that we don't need to add a new copy of every composite type definition for every collection type we want to support, but until that happens, there is not much chance of implementing this feature in a way that is actually standard-conforming. And until then, paying the extra parsing cost for something that isn't going to be standard behavior anyway is not a good trade-off. We have spent countless hours figuring out how to redesign bits of syntax so that they could use already-existing keywords instead of adding new ones; and many more hours angsting about whether there is any way to get rid of some of the keywords we already have. The new options syntax for EXPLAIN and VACUUM exists *primarily* to reduce the number of future keywords we'll need to create. This is a seriously annoying problem, but it's not one we made up just for this patch. We deal with it all the time. Do we sometimes add keywords? Sure, of course we do. But we try to minimize it. It isn't free. I will remove parser changes from the patch; it will add only a few array functions. Then, please let me know functions you don't want to include in the core, if any. I'll remove them at the same time. I posted my thoughts on this topic a week ago. -- 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] SQL/MED - file_fdw
On Sat, Feb 12, 2011 at 01:12, Robert Haas robertmh...@gmail.com wrote: On Wed, Feb 9, 2011 at 2:03 AM, Noah Misch n...@leadboat.com wrote: From a functional and code structure perspective, I find this ready to commit. (I assume you'll drop the XXX: indent only comments on commit.) Kevin, did you want to do that performance testing you spoke of? OK, so is this Ready for Committer, or we're still working on it? Basically, we have no more tasks until the FDW core API is applied. COPY API and file_fdw patches are waiting for it. If we extend them a little more, I'd raise two items: * Should we print foreign table names in error messages? http://archives.postgresql.org/pgsql-hackers/2011-02/msg00427.php * COPY encoding patch was rejected, but using client_encoding is logically wrong for file_fdw. We might need subset of the patch for file_fdw. -- Itagaki Takahiro -- 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] SQL/MED - file_fdw
Robert Haas robertmh...@gmail.com wrote: Noah Misch n...@leadboat.com wrote: From a functional and code structure perspective, I find this ready to commit. (I assume you'll drop the XXX: indent only comments on commit.) Kevin, did you want to do that performance testing you spoke of? OK, so is this Ready for Committer, or we're still working on it? I can run some benchmarks to compare COPY statements with and without the patch this weekend. Noah, does it make more sense to do that with just the copy_export-20110209.patch patch file applied, or in combination with some other FDW patch(es)? -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: Robert Haas robertmh...@gmail.com writes: If we're going to abbreviate transaction, I'd vote for txn over tran, but I think Stephen's point that this is already a lost cause may have some validity. Not sure what other people think. I agree w/ reducing that particular GUC a bit in size, but just to make it clear- that doesn't even come close to solving or fixing the 80-character terminal issue wrt 'show all;'... Aren't we already using xact for that purpose in some user-visible places? But personally I'd be happy with max_pred_locks_per_transaction which gets the worst case down without being too obviously at variance with max_locks_per_transaction. Sounds good to me. The header length for show all would drop to only 206 characters (or so) with that change. If we offered a 'show all;' which didn't include 'description' and didn't have any settings longer than about 46 characters, *then* it'd fit on an 80-char terminal. Of course, if we had multi-line GUC support, we could put each field on a new line and each of those is well under 46 characters.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] SQL/MED - file_fdw
On Fri, Feb 11, 2011 at 11:31 AM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: On Sat, Feb 12, 2011 at 01:12, Robert Haas robertmh...@gmail.com wrote: On Wed, Feb 9, 2011 at 2:03 AM, Noah Misch n...@leadboat.com wrote: From a functional and code structure perspective, I find this ready to commit. (I assume you'll drop the XXX: indent only comments on commit.) Kevin, did you want to do that performance testing you spoke of? OK, so is this Ready for Committer, or we're still working on it? Basically, we have no more tasks until the FDW core API is applied. COPY API and file_fdw patches are waiting for it. If we extend them a little more, I'd raise two items: * Should we print foreign table names in error messages? http://archives.postgresql.org/pgsql-hackers/2011-02/msg00427.php * COPY encoding patch was rejected, but using client_encoding is logically wrong for file_fdw. We might need subset of the patch for file_fdw. It sounds to me like that second issue is a showstopper. I think we either need to reopen discussion on that patch and come up with a resolution that is acceptable ASAP, or we need to punt file_fdw to 9.2. -- 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] pl/python tracebacks
On Fri, Feb 11, 2011 at 11:22 AM, Alex Hunsaker bada...@gmail.com wrote: On Fri, Feb 11, 2011 at 08:45, Robert Haas robertmh...@gmail.com wrote: On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański wulc...@wulczer.org wrote: On 06/02/11 20:12, Jan Urbański wrote: On 27/01/11 22:58, Jan Urbański wrote: On 23/12/10 14:56, Jan Urbański wrote: Here's a patch implementing traceback support for PL/Python mentioned in http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's an incremental patch on top of the plpython-refactor patch sent eariler. Updated to master. Updated to master again. Once more. Alex Hunsaker is listed as the reviewer for this patch, but I don't see a review posted. If this feature is still wanted for 9.1, can someone jump in here? Goodness... I picked up this patch the day before yesterday because no-one was listed. That being said, if anyone else wants to beat me to the punch of reviewing this, have at it! The more eyes the merrier! Sorry, I didn't see when you'd picked it up. I was just keeping an eye on my wall calendar. -- 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] ALTER EXTENSION UPGRADE, v3
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: I can already hear people wanting version aliases instead. We could support e.g. 4 or 5 aliases like 'stable', 'support', 'alpha', 'beta' and maybe 'experimental'. Then rather than defining current_version authors would define any set of those keywords here, and CREATE EXTENSION and ALTER EXTENSION would by default only care for resp. 'stable' and 'support'. Hmm. That might be worth doing, but let's leave it for later when we find out how much demand there really is. It does strike me that what we ought to call the default-version parameter is just default, since that would fit in reasonably well with such an extension later. We could go as far as not requiring anything but considering any unknown parameter as a version alias, or setup a GUC placeholder so that the control file parsing is able to read version.defaut = '1.0' and others. I think having the code do something with any unknown parameter is a seriously bad idea: it removes a useful error check, and it opens a strong likelihood that different versions of PG will interpret the same control file differently. After a bit of reflection I think we should stick with default_version as the parameter name in 9.1. If we want to open it up to allowing arbitrary version aliases later, we can let it accept xxx_version as defining an alias xxx. That seems a lot safer than interpreting any old unrecognized parameter name as a version alias. Then we would just document what the default aliases are used by the commands CREATE EXTENSION and ALTER EXTENSION UPDATE TO. The big advantage of doing so is that it's then easy for extension authors to manage EOL. ALTER EXTENSION foo UPDATE; ERROR: there's no 'support' version available from version 1.2.3 Then you have to write ALTER EXTENSION foo UPDATE TO '2.0' or even UPDATE TO 'stable', and you realise it's a major upgrade, so you need to recheck the extension release notes etc. Uh, not sure how you're envisioning that working? If it fails to find an upgrade script path from the current version to whatever is default, it will still fail to find any path after you explicitly tell it you want to upgrade to that version. 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] SQL/MED - file_fdw
Itagaki Takahiro itagaki.takah...@gmail.com wrote: Basically, we have no more tasks until the FDW core API is applied. COPY API and file_fdw patches are waiting for it. This is something I've found confusing about this patch set, to the point of not knowing what to test, exactly. The COPY API patch and the patch-on-patch for it both applied cleanly *without any of the other patches* and seemed to run fine, even though the post with a patch-on-patch for the COPY API said that several other patches needed to be applied first. In spite of having tried to follow the posts for all the FDW threads, I'm still confused enough about the relationship between these patches to be unsure what to test. My top priority for testing would be to confirm that there is no adverse impact on existing COPY performance from the refactoring. -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] ALTER EXTENSION UPGRADE, v3
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Is there a test somewhere that when CREATE OR REPLACE FUNCTION runs from an extension's script at upgrade, the function must already be attached to the extension if it exists in the system? Ditto for views etc? IIRC, the current behavior is that C.O.R.F. on an existing function preserves the function's existing extension membership, if any. It doesn't matter whether you are doing it from an extension script or not. I'm not really eager to change that, and I doubt it would make any difference anyway to the use-case under consideration --- if the 1.0-to-1.1 script is adding a function, it's unlikely the function existed pre-1.0 ... 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] SQL/MED - file_fdw
On Fri, Feb 11, 2011 at 10:31:08AM -0600, Kevin Grittner wrote: Robert Haas robertmh...@gmail.com wrote: Noah Misch n...@leadboat.com wrote: From a functional and code structure perspective, I find this ready to commit. (I assume you'll drop the XXX: indent only comments on commit.) Kevin, did you want to do that performance testing you spoke of? OK, so is this Ready for Committer, or we're still working on it? I can run some benchmarks to compare COPY statements with and without the patch this weekend. Noah, does it make more sense to do that with just the copy_export-20110209.patch patch file applied, or in combination with some other FDW patch(es)? I'd say, run them with this patch alone. The important thing is to not penalize existing COPY users. Incidentally, the did you want ... ? was a genuine question. I see very little performance risk here, so the tests could be quite cursory, even absent entirely. 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] Add support for logging the current role
Stephen Frost sfr...@snowman.net writes: * Itagaki Takahiro (itagaki.takah...@gmail.com) wrote: You might need yum install openjade stylesheets or similar packages and re-configure. I've got openjade, etc, installed, but I'm on Debian and it doesn't appear to include that collateindex.pl anywhere.. FWIW, on Fedora 13 I see $ which collateindex.pl /usr/bin/collateindex.pl $ rpm -qf /usr/bin/collateindex.pl docbook-style-dsssl-1.79-11.fc13.noarch $ rpm -qi docbook-style-dsssl Name: docbook-style-dsssl Relocations: (not relocatable) Version : 1.79 Vendor: Fedora Project Release : 11.fc13 Build Date: Mon Jun 7 10:06:48 2010 Install Date: Fri Oct 1 10:07:37 2010 Build Host: x86-07.phx2.fedoraproject.org Group : Applications/Text Source RPM: docbook-style-dsssl-1.79-11.fc13.src.rpm Size: 2308505 License: Copyright only Signature : RSA/SHA256, Mon Jun 7 10:34:27 2010, Key ID 7edc6ad6e8e40fde Packager: Fedora Project URL : http://docbook.sourceforge.net/ Summary : Norman Walsh's modular stylesheets for DocBook Description : These DSSSL stylesheets allow to convert any DocBook document to another printed (for example, RTF or PostScript) or online (for example, HTML) format. They are highly customizable. 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] Change pg_last_xlog_receive_location not to move backwards
Fujii, all, * Fujii Masao (masao.fu...@gmail.com) wrote: That logic exists because we'd like to check that newly-received WAL data is consistent with previous one by validating the header of new WAL file. So since we need the header of new WAL file, we retreat the replication starting location to the beginning of the WAL file when reconnecting to the primary. Thanks for that explanation, but I can't help but wonder why it doesn't make more sense to introduce a new variable to track the value you want rather than reusing an existing one and then adding a variable to represent what the old variable was already doing. In other words, why not invent XLogRecPtr newestReceviedUpto; /* or something */ and update that as necessary and have the function you want changed return that, and leave receivedUpto alone..? It seems like it'd be a lot easier to prove to ourselves that your patch didn't break anything, presuming the function we're talking about changing the return value of isn't called anywhere (seems rather unlikely to me..). Also, you really should reformat the docs properly when you change them, rather than leaving the lines ragged.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Add support for logging the current role
Excerpts from Tom Lane's message of vie feb 11 13:49:33 -0300 2011: Stephen Frost sfr...@snowman.net writes: * Itagaki Takahiro (itagaki.takah...@gmail.com) wrote: You might need yum install openjade stylesheets or similar packages and re-configure. I've got openjade, etc, installed, but I'm on Debian and it doesn't appear to include that collateindex.pl anywhere.. $ apt-file search collateindex.pl docbook-dsssl: /usr/bin/collateindex.pl docbook-dsssl: /usr/share/man/man1/collateindex.pl.1.gz -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 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] Range Types: -|- ops vs empty range
On Fri, 2011-02-11 at 15:09 +0100, Erik Rijkers wrote: On Wed, February 9, 2011 09:35, Jeff Davis wrote: Updated patch. The operators and -|- have the following behavior with empty ranges: testdb=# select '-'::int4range range(200,300); ERROR: empty range testdb=# select '-'::int4range range(200,300); ERROR: empty range testdb=# select '-'::int4range -|- range(200,300); ERROR: empty range I'm not sure if that is deliberate behavior, but they seem almost bugs to me. It's deliberate, but it looks like the error messages could use some improvement. Wouldn't it be better (and more practical) if these would return false (or perhaps NULL, for 'unknown') ? I'm hesitant to return NULL when the inputs are known. If we were to define these functions for empty ranges, I would think they would all return true. and (strictly left of and strictly right of, respectively) could be seen to start out as true and return false if it finds a point overlapping or on the other side. The primary use case for -|- (adjacent) is to see if your ranges are contiguous and non-overlapping. For empty ranges, that seems to be true. I'm not disagreeing with your interpretation really. I think that different people will assume different behavior, and so it's more likely to cause confusion. An error early on will allow them to do something like: CASE WHEN myrange? THEN myrange -|- range(10,20) ELSE TRUE END So that they (and anyone who reads their query) can see explicitly what's happening, without looking in the manual for details. I'm open to suggestion, however. If we can get a reasonable consensus on the values these functions should return, I'll change it. Regards, Jeff Davis -- 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: $ which collateindex.pl /usr/bin/collateindex.pl $ rpm -qf /usr/bin/collateindex.pl docbook-style-dsssl-1.79-11.fc13.noarch Ah-hah, thanks for that! Apparently on Debian it's docbook-dsssl that contains it, and yes, it gets installed into /usr/bin (not /bin, should have figured that..). I'll give building the docs another shot. Thanks again, Stephen signature.asc Description: Digital signature
Re: [HACKERS] ALTER EXTENSION UPGRADE, v3
Tom Lane t...@sss.pgh.pa.us writes: After a bit of reflection I think we should stick with default_version as the parameter name in 9.1. If we want to open it up to allowing arbitrary version aliases later, we can let it accept xxx_version as defining an alias xxx. That seems a lot safer than interpreting any old unrecognized parameter name as a version alias. That was my first idea, like I did with upgrade_from_xxx, but though you wouldn't like it so much, so proposed the version.xxx form instead :) ALTER EXTENSION foo UPDATE; ERROR: there's no 'support' version available from version 1.2.3 Then you have to write ALTER EXTENSION foo UPDATE TO '2.0' or even UPDATE TO 'stable', and you realise it's a major upgrade, so you need to recheck the extension release notes etc. Uh, not sure how you're envisioning that working? If it fails to find an upgrade script path from the current version to whatever is default, it will still fail to find any path after you explicitly tell it you want to upgrade to that version. That's not exactly what happens here. There would be no support version alias in the control file, so no way to upgrade to it, and support would happen to be what ALTER EXTENSION foo UPDATE would consider when you don't mention explicitly the target version. However, when you do say that you want to upgrade to '2.0' or to 'stable', now the upgrade script certainly exists and the version alias too, so that the upgrade is possible. Only explicitly though. 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] SQL/MED - file_fdw
Noah Misch n...@leadboat.com wrote: I'd say, run them with this patch alone. The important thing is to not penalize existing COPY users. Sounds good. Incidentally, the did you want ... ? was a genuine question. I see very little performance risk here, so the tests could be quite cursory, even absent entirely. From what I've seen, I tend to agree. If there's a committer ready to go over this, I would say that it might be worth waiting for the benchmark results against the patch from the day before yesterday to be run before pulling the trigger on it; but proceed on the basis that it's a near-certainty that it will test out OK. -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] Range Types: -|- ops vs empty range
On Fri, Feb 11, 2011 at 11:55 AM, Jeff Davis pg...@j-davis.com wrote: On Fri, 2011-02-11 at 15:09 +0100, Erik Rijkers wrote: On Wed, February 9, 2011 09:35, Jeff Davis wrote: Updated patch. The operators and -|- have the following behavior with empty ranges: testdb=# select '-'::int4range range(200,300); ERROR: empty range testdb=# select '-'::int4range range(200,300); ERROR: empty range testdb=# select '-'::int4range -|- range(200,300); ERROR: empty range I'm not sure if that is deliberate behavior, but they seem almost bugs to me. It's deliberate, but it looks like the error messages could use some improvement. Wouldn't it be better (and more practical) if these would return false (or perhaps NULL, for 'unknown') ? I'm hesitant to return NULL when the inputs are known. If we were to define these functions for empty ranges, I would think they would all return true. and (strictly left of and strictly right of, respectively) could be seen to start out as true and return false if it finds a point overlapping or on the other side. The primary use case for -|- (adjacent) is to see if your ranges are contiguous and non-overlapping. For empty ranges, that seems to be true. I'm not disagreeing with your interpretation really. I think that different people will assume different behavior, and so it's more likely to cause confusion. An error early on will allow them to do something like: CASE WHEN myrange? THEN myrange -|- range(10,20) ELSE TRUE END So that they (and anyone who reads their query) can see explicitly what's happening, without looking in the manual for details. I'm open to suggestion, however. If we can get a reasonable consensus on the values these functions should return, I'll change it. For what it's worth, my completely uninformed opinion is that comparison operators shouldn't error out. I haven't read the patch so I'm not sure what those operators are defined to do, though. -- 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] ALTER EXTENSION UPGRADE, v3
Tom Lane t...@sss.pgh.pa.us writes: 1. If you pick the wrong FROM version, the upgrade script will almost certainly fail, because the objects won't exist or won't be in the state it expects (ie, not already members of the extension). IIRC, the current behavior is that C.O.R.F. on an existing function preserves the function's existing extension membership, if any. Right. But it does not catch the case when you CORF on a function that is not already into the extension. I don't see how to distinguish that from adding a new function into it at upgrade time. So I'm having a hard time understanding what you meant in your point above. 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] ALTER EXTENSION UPGRADE, v3
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: Uh, not sure how you're envisioning that working? If it fails to find an upgrade script path from the current version to whatever is default, it will still fail to find any path after you explicitly tell it you want to upgrade to that version. That's not exactly what happens here. There would be no support version alias in the control file, so no way to upgrade to it, and support would happen to be what ALTER EXTENSION foo UPDATE would consider when you don't mention explicitly the target version. However, when you do say that you want to upgrade to '2.0' or to 'stable', now the upgrade script certainly exists and the version alias too, so that the upgrade is possible. Only explicitly though. Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a different default version name from what CREATE EXTENSION uses (unless you're willing to also break use of CREATE EXTENSION without an explicit target version). I was intending to have default_version identify the default target for both cases. While we could have different parameters for the two cases, I think it would mostly just cause confusion. 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] pl/python tracebacks
Robert Haas robertmh...@gmail.com wrote: Goodness... I picked up this patch the day before yesterday because no-one was listed. That being said, if anyone else wants to beat me to the punch of reviewing this, have at it! The more eyes the merrier! Sorry, I didn't see when you'd picked it up. I was just keeping an eye on my wall calendar. [OT] FWIW, this is the sort of situation which caused me to suggest that the web app somehow show the date of the last reviewer change when it is past the Last Activity date. I don't really care whether it would be in the Reviewers column or as a second line, in parentheses, in the Last Activity column. I would find it useful when managing a CF, anyway -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] FOR KEY LOCK foreign keys
Excerpts from Noah Misch's message of vie feb 11 04:13:22 -0300 2011: Hello, First, thanks for the very thorough review. On Thu, Jan 13, 2011 at 06:58:09PM -0300, Alvaro Herrera wrote: Incidentally, HeapTupleSatisfiesMVCC has some bits of code like this (not new): /* MultiXacts are currently only allowed to lock tuples */ Assert(tuple-t_infomask HEAP_IS_LOCKED); They're specifically only allowed for SHARE and KEY locks, right? heap_lock_tuple seems to assume as much. Yeah, since FOR UPDATE acquires an exclusive lock on the tuple, you can't have a multixact there. Maybe we can make the assert more specific; I'll have a look. [ test case with funny visibility behavior ] Looking into the visibility bug. I published about this here: http://commandprompt.com/blogs/alvaro_herrera/2010/11/fixing_foreign_key_deadlocks_part_2/ So, as a rough design, 1. Create a new SELECT locking clause. For now, we're calling it SELECT FOR KEY LOCK 2. This will acquire a new type of lock in the tuple, dubbed a keylock. 3. This lock will conflict with DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE. It does not conflict with SELECT FOR SHARE, does it? It doesn't; I think I copied old text there. (I had originally thought that they would conflict, but I had to change that due to implementation restrictions). The odd thing here is the checking of an outside condition to decide whether locks conflict. Normally, to get a different conflict list, we add another lock type. What about this? FOR KEY SHARE conflicts with FOR KEY UPDATE FOR SHARE conflicts with FOR KEY UPDATE, FOR UPDATE FOR UPDATE conflicts with FOR KEY UPDATE, FOR UPDATE, FOR SHARE FOR KEY UPDATE conflicts with FOR KEY UPDATE, FOR UPDATE, FOR SHARE, FOR KEY SHARE Hmm, let me see about this. 3. The original tuple needs to be marked with the Cmax of the locking command, to prevent it from being seen in the same transaction. Could you elaborate on this requirement? Consider an open cursor with a snapshot prior to the lock. If we leave the old tuple as is, the cursor would see that old tuple as visible. But the locked copy of the tuple is also visible, because the Cmax is just a locker, not an updater. 4. A non-conflicting update to the tuple must carry forward some fields from the original tuple into the updated copy. Those include Xmax, XMAX_IS_MULTI, XMAX_KEY_LOCK, and the CommandId and COMBO_CID flag. HeapTupleHeaderGetCmax() has this assertion: /* We do not store cmax when locking a tuple */ Assert(!(tup-t_infomask (HEAP_MOVED | HEAP_IS_LOCKED))); Assuming that assertion is still valid, there will never be a HEAP_COMBOCID flag to copy. Right? Hmm, I think the assert is wrong, but I'm still paging in the details of the patch after being away from it for so long. Let me think more about it. [ Lots more stuff ] I'll give careful consideration to all this. Thanks again for the detailed review. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 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] Careful PL/Perl Release Not Required
On Feb 10, 2011, at 11:43 PM, Alex Hunsaker wrote: I'd like to quibble with you over this point if I may. :-) Per perldoc: JSON::XS utf8 flag disabled When utf8 is disabled (the default), then encode/decode generate and expect Unicode strings ... So - If you are on 9.1 and a utf8 database you want to pass utf8(false), as you have a Unicode string. Right. That's what I realized yesterday, thanks to our exchange. I updated my code for that. The use of the term Unicode string in the JSON::XS docs is really confusing, though. A scalar with the utf8 flag on is not a unicode string. It's Perl's representation of a string. It has no encoding (it's decoded). Like I said, the terminology is awful. - If you are on 9.1 and on a non utf8 database you would want to pass utf8(false) as the string is *not* Unicode, its byte soup. Its in some _other_ encoding say EUC_JP. You would need to decode() it into Unicode first. Or use utf8() or utf8(1). Then JSON::XS will decode it for you. - If you are on 9.1 and a utf8 database you still want to pass utf8(false) as the string is still unicode. - if you are on 9.1 and a non utf8 database you want to pass utf8(false) as the string is _now_ unicode. Right. So... it seems you always want to pass false. The only case I can where you would want to pass true is you are on 9.1 with a SQL_ASCII database and you know for a fact the string represents a utf8 byte sequence. Or am I missing something obvious? Yes, that you can pass no value to utf8() or a true value and it will decode a utf-8-encoded string for you. If you do have to change your semantics/functions, could you post an example? I'd like to make sure its because you were hitting one of those nasty corner cases and not something new is broken. I think that people who have non-utf-8 databases might be surprised. Yeah, surprised it does the right thing and its actually usable now ;). Yes, but they might need to change their code, is what I'm saying. This probably won't be that common, but Oleg, for example, will need to convert his fixed function from: No, he had to add the decode line, IIRC: CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS $$ use strict; use URI::Escape; utf8::decode($_[0]); return uri_unescape($_[0]); $$ LANGUAGE plperlu; Because uri_unescape() needs its argument to be decoded to Perl's internal form. On 9.1, it will be, so he won't need to call utf8::decode(). That is, in a latin-1 database: Meh, no, not really. He will still need to call decode. Why? In 9.1, won't params from passed to PL/Perl functions in non-SQL_ASCII databases already be decoded? The problem is uri_unescape() does not assume an encoding on the URI. It could be UTF-16 encoded for all it knows (UTF-8 is probably standard, but thats not the point, it knows nothing about Unicode or encodings). Yes, but if you don't want surprises, I think you want to pass a decoded string to it. For example, lets say you have a latin-1 accented e é the byte sequence is the one byte: 0xe9. If you were to uri_escape that you get the 3 byte ascii string %E9: $ perl -E 'use URI::Escape; my $str = \xe9; say uri_escape($str)' %E9 If you uri_unescape %E9 you get 1 byte back with a hex value of 0xe9: $ perl -E 'use URI::Escape; my $str = uri_unescape(%E9); say sprintf(chr: %s hex: %s, len: %s, $str, unpack(H*, $str), length $str)' chr: é hex: e9, len: 1 What if we want to uri_escape a UTF-16 accented e? Thats two hex bytes 0x00e9: $ perl -E 'use URI::Escape; my $str = \x00\xe9; say uri_escape($str)' %00%E9 What happens we uri_unescape that? Do we get back a Unicode string that has one character? No. And why should we? How is uri_unescape supposed to know what %00%E9 represent? All it knows is thats 2 separate bytes: $ perl -E 'use URI::Escape; my $str = uri_unescape(%00%E9); say sprintf(chr: %s hex: %s, len: %s, $str, unpack(H*, $str), length $str)' chr: é hex: 00e9, len: 2 Yeah, this is why URI::Escape needs a uri_unescape_utf8() function to complement utf8_escape_utf8(). But to get around that, you would of course decode the return value yourself. Now, lets say you want to uri_escape a utf8 accented e, thats the two byte sequence: 0xc3 0xa9: $ perl -E 'use URI::Escape; my $str = \xc3\xa9; say uri_escape($str)' %C3%A9 Ok, what happens when we uri_unescape those?: $ perl -E 'use URI::Escape; my $str = uri_unescape(%C3%A9); say sprintf(chr: %s hex: %s, len: %s, $str, unpack(H*, $str), length $str)' chr: é hex: c3a9, len: 2 So, plperl will also return 2 characters here. In the the cited case he was passing %C3%A9 to uri_unescape() and expecting it to return 1 character. The additional utf8::decode() will tell perl the string is in utf8 so it will then return 1 char. The point being, decode is needed and with it, the function will work pre and post 9.1. Why wouldn't the string be decoded
Re: [HACKERS] Change pg_last_xlog_receive_location not to move backwards
On Fri, Feb 11, 2011 at 11:52 AM, Stephen Frost sfr...@snowman.net wrote: Fujii, all, * Fujii Masao (masao.fu...@gmail.com) wrote: That logic exists because we'd like to check that newly-received WAL data is consistent with previous one by validating the header of new WAL file. So since we need the header of new WAL file, we retreat the replication starting location to the beginning of the WAL file when reconnecting to the primary. Thanks for that explanation, but I can't help but wonder why it doesn't make more sense to introduce a new variable to track the value you want rather than reusing an existing one and then adding a variable to represent what the old variable was already doing. +1. It seems like there may be some more significant changes in this area needed; however, for now I think the best fix is the one with the least chance of breaking anything. Also, you really should reformat the docs properly when you change them, rather than leaving the lines ragged.. It's OK to leave them a little ragged, I think. It eases back-patching. -- 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] Range Types: -|- ops vs empty range
On Fri, 2011-02-11 at 12:03 -0500, Robert Haas wrote: For what it's worth, my completely uninformed opinion is that comparison operators shouldn't error out. I haven't read the patch so I'm not sure what those operators are defined to do, though. means strictly right of means strictly left of -|- means adjacent (touching but not overlapping) I'm open to suggestion about how those behave with empty ranges. Regards, Jeff Davis -- 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] Change pg_last_xlog_receive_location not to move backwards
On Fri, Feb 11, 2011 at 12:25 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Feb 11, 2011 at 11:52 AM, Stephen Frost sfr...@snowman.net wrote: Fujii, all, * Fujii Masao (masao.fu...@gmail.com) wrote: That logic exists because we'd like to check that newly-received WAL data is consistent with previous one by validating the header of new WAL file. So since we need the header of new WAL file, we retreat the replication starting location to the beginning of the WAL file when reconnecting to the primary. Thanks for that explanation, but I can't help but wonder why it doesn't make more sense to introduce a new variable to track the value you want rather than reusing an existing one and then adding a variable to represent what the old variable was already doing. +1. It seems like there may be some more significant changes in this area needed; however, for now I think the best fix is the one with the least chance of breaking anything. Actually... wait a minute. Now that I'm thinking about this a little more, I'm not so convinced. If we leave this the way is, and just paper over the problem using the method Stephen and I both had in mind, then we could be streaming from a position that precedes the so-called current position. And worse, the newly introduced replies to the master will still show the position going backward, so the master will reflect a position that is earlier that the position the slave reports for itself, not because of any real difference but because of a reporting difference. That sure doesn't seem good. -- 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] Careful PL/Perl Release Not Required
On 02/11/2011 12:16 PM, David E. Wheeler wrote: [long discussion elided] Is there an action item here? Is the documentation inadequate or inaccurate? If so, please make a suggestion for improved wording. I certainly expect the change to be covered in the release notes. You can check on the prominence given the item then and protest if you don't think it's adequate. 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] ALTER EXTENSION UPGRADE, v3
Tom Lane t...@sss.pgh.pa.us writes: That's not exactly what happens here. There would be no support version alias in the control file, so no way to upgrade to it, and support would happen to be what ALTER EXTENSION foo UPDATE would consider when you don't mention explicitly the target version. However, when you do say that you want to upgrade to '2.0' or to 'stable', now the upgrade script certainly exists and the version alias too, so that the upgrade is possible. Only explicitly though. Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a different default version name from what CREATE EXTENSION uses (unless Yes. I see that as a good feature to have. stable and support looks like good default aliases for me, but again, IANANS (native speaker). you're willing to also break use of CREATE EXTENSION without an explicit target version). I was intending to have default_version identify the default target for both cases. While we could have different parameters for the two cases, I think it would mostly just cause confusion. I happen to think it would avoid too much confusion myself. There's a semantic difference here, that's not just playing with keywords. And we're adding nice error checks to help stay on the safe side. 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] ALTER EXTENSION UPGRADE, v3
OK, let me see if I can summarize what I think we've agreed to: CREATE syntax is extended to CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv] If VERSION is not specified, v is taken from default_version in the control file, or fail if that's not given either. We create the pg_extension entry and then run the script extname-v.sql, or extname-oldv-v.sql if FROM is present. ALTER syntax is extended with ALTER EXTENSION extname UPDATE [TO v] Again, if v is not specified, it is taken from default_version in the control file, or fail if that's not given either. Here we take oldv from the current pg_extension.extversion field, and then run the script extname-oldv-v.sql. We will add logic to find a chain of update scripts leading from oldv to v, in case that exact combination is not available in the extension's script directory. (NOTE: maybe in the CREATE ... FROM case, it would be a better idea to not do that search, but insist on finding exactly extname-oldv-v.sql? That would provide at least a little bit of extra protection against wrong FROM choice. Not sure how much it helps though.) Version identifiers will be ColId_or_Sconst in the grammar, ie, you can omit quotes if they're valid SQL identifiers. I'm not sure this helps with typical choices of version strings, but we might as well allow it. Version strings will have no hard-wired semantics except equality; we don't need a sorting rule. We must however forbid - in version strings, to avoid ambiguity as to whether a file name represents an install or upgrade script. (Note: - in extension names poses a hazard as well; not within a single extension, but for example foo-bar's install scripts could be confused with foo's upgrade scripts. However, I think we need not forbid - in extension names since this risk can be avoided by giving foo-bar its own script directory.) It also seems to me to be a good idea to forbid .. and directory separators in both types of names, because otherwise CREATE EXTENSION could be used to probe the file system. That's not really an issue right now, with use of the command being restricted to superusers anyway, but it's inevitable that we'll want to relax that restriction. We will also add code to allow per-version control files extname-v.control in the script directory. After determining the version we plan to install or update to, we read the per-version control file if any, and let it override parameters from the primary control file. (This implies for example that a per-version control file's encoding setting would control all update scripts read while trying to get to that version. I'm not sure how useful that is --- given the chaining behavior, really you're going to have to use the same encoding throughout the extension's update files. Maybe better to disallow encoding in per-version control files?) Comments? 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] Range Types: -|- ops vs empty range
On Fri, Feb 11, 2011 at 12:26 PM, Jeff Davis pg...@j-davis.com wrote: On Fri, 2011-02-11 at 12:03 -0500, Robert Haas wrote: For what it's worth, my completely uninformed opinion is that comparison operators shouldn't error out. I haven't read the patch so I'm not sure what those operators are defined to do, though. means strictly right of means strictly left of -|- means adjacent (touching but not overlapping) I'm open to suggestion about how those behave with empty ranges. Hmm, so an empty range is a range that includes nothing at all, right? Not everything in the world? Are we sure we even want to have that concept? -- 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] Careful PL/Perl Release Not Required
On Fri, Feb 11, 2011 at 10:16, David E. Wheeler da...@kineticode.com wrote: On Feb 10, 2011, at 11:43 PM, Alex Hunsaker wrote: Like I said, the terminology is awful. Yeah I use encode and decode to mean the same thing frequently :-(. In the the cited case he was passing %C3%A9 to uri_unescape() and expecting it to return 1 character. The additional utf8::decode() will tell perl the string is in utf8 so it will then return 1 char. The point being, decode is needed and with it, the function will work pre and post 9.1. Why wouldn't the string be decoded already when it's passed to the function, as it would be in 9.0 if the database was utf-8, and should be in 9.1 if the database isn't sql_ascii? It is decoded... the input string %C3%A9 actually is the _same_ string utf-8, latin1 and SQL_ASCII decoded or not. Those are all ascii characters. Calling utf8::decode(%C3%A9) is essentially a noop. In-fact on a latin-1 database it sure as heck better return two characters, it would be a bug if it only returned 1 as that would mean it would be treating a series of latin1 bytes as a series of utf8 bytes! If it's a latin-1 database, in 9.1, the argument should be passed decoded. That's not a utf-8 string or bytes. It's Perl's internal representation. If I understand the patch correctly, the decode() will no longer be needed. The string will *already* be decoded. Ok, I think i figured out why we seem to be talking past each other, we have: CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS $$ use strict; use URI::Escape; utf8::decode($_[0]); return uri_unescape($_[0]); $$ LANGUAGE plperlu; That *looks* like it is decoding the input string, which it is, but actually that will double utf8 encode your string. It does not seem to in this case because we are dealing with all ascii input. The trick here is its also telling perl to decode/treat the *output* string as utf8. uri_unescape() returns the same string you passed in, which thanks to the utf8::decode() above has the utf8 flag set. Meaning we end up treating it as 1 character instead of two. Or basically that it has the same effect as calling utf8::decode() on the return value. The correct way to write that function pre 9.1 and post 9.1 would be (in a utf8 database): CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS $$ use strict; use URI::Escape; my $str = uri_unescape($_[0]); utf8::decode($str); return $str; $$ LANGUAGE plperlu; The last utf8::decode being optional (as we said, it might not be utf8), but granting the sought behavior by the op. -- 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] Range Types: -|- ops vs empty range
Jeff Davis pg...@j-davis.com wrote: means strictly right of means strictly left of -|- means adjacent (touching but not overlapping) I'm open to suggestion about how those behave with empty ranges. OK, that still leaves a lot to the imagination, though. To try to clarify in *my* mind: empty range = Zero length? If so, is it fixed at some point, but empty? '(x,x)'? '[x,x)'? Is it everything? '[-inf,+inf]'? Is it really meaningfully distinct from NULL? Where do you see it being useful? -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
Michael Banck wrote: On Thu, Feb 10, 2011 at 06:04:46PM -0500, Tom Lane wrote: Less narrow-minded interpretation of GPL requirements, perhaps. (And yes, we have real lawyers on staff considering these issues.) Is their opinion public/can be made public? This might possibly lead to a re-evaluation of the situation by Debian. I doubt that. This is one of those situations where there is an ideological position held by the FSF and Debian that's unlikely to budge, but one that has limited testing in court. I believe that RedHat's lawyers have assessed the business risk here and judged it not sufficient to worry about. But their opinion on that isn't going to sway anyone evaluating this primarily on free software principles. I had to trace down the history here once before while working on another project that couldn't link with readline; here's a timeline with all the latest fun parts at the end: http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL : Early discussion with RMS about why linking with readline requires code using it be GPL, and why the user did the linking and I wrapped it aren't escape routes. http://www.gnu.org/licenses/gpl-2.0.html : The GPLv2 includes the following in section 3: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. This provides some relief to people building software on their own, but when you're the OS packager it doesn't help because you are providing the components and the executables. http://lists.debian.org/debian-legal/2002/10/msg00113.html : Discussion of the exemption made for GPL libraries shipping with an OS, and an early mention of Debian['s] current hardline position on the GPL+OpenSSL licensing issue http://bugs.ntp.org/show_bug.cgi?id=931 : ntp runs into readline concerns. Pull quote: What is less clear is the claim that the FSF makes that any program written to even *use* the readline API is also a derived work. This hasn't been tested in court yet, so its validity is questionable. However, that is their claim. http://people.gnome.org/~markmc/openssl-and-the-gpl.html : Why OpenSSL is particularly troublesome here. This describes the now common OpenSSL exemption as a suggested workaround for projects who can modify their license terms. http://lists.debian.org/debian-legal/2004/05/msg00595.html : Example of adding an OpenSSL exemption http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php : A patch adding GnuTLS support is submitted to PostgreSQL. It's rejected mainly because the code is so large/obtrusive. TODO item Consider GnuTLS if OpenSSL license becomes a problem added. [Hint: it's now become a problem] http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php : More PostgreSQL discussion that predicts a collision with Debian policy is coming. Concerns about the quality fo the GnuTLS API relative to the feature set provided by OpenSSL are raised too, as impediments toward switch away from OpenSSL. http://archives.postgresql.org/pgsql-hackers/2006-12/msg01224.php : List of GPL applications that use libpq in Debian. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498857 : Python runs into the readline+OpenSSL issue http://redmine.ruby-lang.org/issues/show/2982 : Ruby runs into the readline+OpenSSL issue http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601754 : PostgreSQL runs into the readline+OpenSSL issue on Debian Lenny. Note that this bug being open means it's possible all these problems in Squeeze are going to get backported to Lenny and break stable server installs all over the world one day in our near future. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603599 : Dupe of the bug for 9.0+Squeeze. This is the one that was fixed by switching to libedit. Then we have the stream of bugs cascading out of that decision: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605313 : Delete key stopped working in psql http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109 : Cannot input multibyte characters in psql http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607907 : Missing readline features http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442 : Input of non-ASCII characters broken http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611918 : psql segfaults in libedit So where are we at? -GNU libreadine is certainly never going to add an OpenSSL exemption -If the OpenSSL project was going to switch to a reasonable license, they'd have done it years ago -There are many known and serious bugs/limitations in libedit relative to libreadline -Adding GnuTLS support to PostgreSQL would require solving several code quality issues
Re: [HACKERS] Change pg_last_xlog_receive_location not to move backwards
* Robert Haas (robertmh...@gmail.com) wrote: Actually... wait a minute. Now that I'm thinking about this a little more, I'm not so convinced. If we leave this the way is, and just paper over the problem using the method Stephen and I both had in mind, then we could be streaming from a position that precedes the so-called current position. And worse, the newly introduced replies to the master will still show the position going backward, so the master will reflect a position that is earlier that the position the slave reports for itself, not because of any real difference but because of a reporting difference. That sure doesn't seem good. I'm really not sure it's as bad as all that... The slave and the master are only going to be out of sync wrt position until the slave sends the request for update to the master, gets back the result, and checks the XLOG header, right? Here's my question- we're talking about if the master dies here, as I understand it. If the slave comes up and can't get to the master, is he going to be reporting the older position, or his current one? The answer to that should be, I believe, the *current* one. He'd only go backwards *if* the master is up and he gets his request over to the master to get the old log. In fact, if he comes up and gets his request off to the master and the master never replies, in my view, he should be able to be restarted into 'master' mode and come all the way up to 'current' (which would be later than what he was trying to ask the master for). *That* is the value, I think, that Fujii is looking for- if this slave started up as a master, where would he be? That should always be increasing. The fact that we back up a little, as a double-check to make sure we didn't get wildly out of sync, and because we want the master to only be producing full XLOGs, is an implementation detail, really, that probably doesn't really need to be exposed.. That may mean that we want to change what the slave is reporting for itself though, if it's currently allowed to be seen going backwards, but I don't think that would be terribly difficult to change... I havn't really dug into the SR/HS stuff, so I could be way off too.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Range Types: -|- ops vs empty range
On 02/11/2011 12:36 PM, Robert Haas wrote: On Fri, Feb 11, 2011 at 12:26 PM, Jeff Davispg...@j-davis.com wrote: On Fri, 2011-02-11 at 12:03 -0500, Robert Haas wrote: For what it's worth, my completely uninformed opinion is that comparison operators shouldn't error out. I haven't read the patch so I'm not sure what those operators are defined to do, though. means strictly right of means strictly left of -|- means adjacent (touching but not overlapping) I'm open to suggestion about how those behave with empty ranges. Hmm, so an empty range is a range that includes nothing at all, right? Not everything in the world? Are we sure we even want to have that concept? I have no particular opinion on that, but if we do then ISTM all the above (and particularly the last) should return false if either operand is an empty range. 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] Careful PL/Perl Release Not Required
On Fri, Feb 11, 2011 at 10:44, Alex Hunsaker bada...@gmail.com wrote: On Fri, Feb 11, 2011 at 10:16, David E. Wheeler da...@kineticode.com wrote: That *looks* like it is decoding the input string, which it is, but actually that will double utf8 encode your string. It does not seem to in this case because we are dealing with all ascii input. The trick here is its also telling perl to decode/treat the *output* string as utf8. Urp, this is a bit of a fib. The problem is actual in plperl not perl persay. Pre 9.1 we always fetched perls internal string *ignoring* the utf8 flag. So if you had octets that were utf8 things would work. The utf8::decode($_[0]); uri_unescape($_[0]); happened to make the return string internally be utf8 and so it would only return 1 char. Thats what the op wanted and why it seemed to fix his problem. But thats actually a bug! utf8::decode($_[0]) should not have changed anything at all on the output side. It should still have returned 2 characters instead of 1. -- 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] Range Types: -|- ops vs empty range
empty range = Zero length? If so, is it fixed at some point, but empty? '(x,x)'? '[x,x)'? Neither of the above should be possible, I think. The expression (x logically excludes the expression x). However, [x,x] would be valid, and would be a zero-length interval at the point x. Is it everything? '[-inf,+inf]'? No, that's everything which is a different concept. The above also ought to be possible, and overlap everything. Is it really meaningfully distinct from NULL? Yes. NULL means I don't know. If a range type IS NULL, then any operation performed with it ought to be NULL. Hence: IF y x, THEN: [x,x] [y,z) == TRUE [x,x] -|- (x,y] == TRUE NULL [y,z} IS NULL [-inf,+inf] [y,z) == FALSE I can imagine using all of these constructs in actual applications. In fact, I have *already* used [-inf,+inf] -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.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] Careful PL/Perl Release Not Required
On Feb 11, 2011, at 9:44 AM, Alex Hunsaker wrote: It is decoded... the input string %C3%A9 actually is the _same_ string utf-8, latin1 and SQL_ASCII decoded or not. Those are all ascii characters. Calling utf8::decode(%C3%A9) is essentially a noop. No, it's not decoded. It doesn't matter because they're ASCII bytes. But if the utf8 flag isn't set, it's not decoded. It's just byte soup as far as Perl is concerned. Unless I grossly misunderstand something, which is entirely possible. Ok, I think i figured out why we seem to be talking past each other, we have: CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS $$ use strict; use URI::Escape; utf8::decode($_[0]); return uri_unescape($_[0]); $$ LANGUAGE plperlu; That *looks* like it is decoding the input string, which it is, but actually that will double utf8 encode your string. It does not seem to in this case because we are dealing with all ascii input. The trick here is its also telling perl to decode/treat the *output* string as utf8. uri_unescape() returns the same string you passed in, which thanks to the utf8::decode() above has the utf8 flag set. Meaning we end up treating it as 1 character instead of two. Or basically that it has the same effect as calling utf8::decode() on the return value. The correct way to write that function pre 9.1 and post 9.1 would be (in a utf8 database): CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS $$ use strict; use URI::Escape; my $str = uri_unescape($_[0]); utf8::decode($str); return $str; $$ LANGUAGE plperlu; The last utf8::decode being optional (as we said, it might not be utf8), but granting the sought behavior by the op. No. If the argument to PL/Perl has the utf8 flag set, then that's what you always get. The utf8::decode() isn't necessary because it's already decoded: perl -MURI::Escape -MEncode -E 'say utf8::is_utf8(uri_unescape(Encode::decode_utf8(“hi”)))' 1 Best, David -- 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
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a different default version name from what CREATE EXTENSION uses (unless Yes. I see that as a good feature to have. stable and support looks like good default aliases for me, but again, IANANS (native speaker). I'm not very happy with that at all, either as to the concept or the specific version-alias names. I don't think that CREATE and ALTER really need different default version targets. And those choices of names carry far too much baggage. Default is what they are as far as the system is concerned, but names like those imply a lot more. Anybody else have an opinion on this detail? 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] Careful PL/Perl Release Not Required
On Feb 11, 2011, at 9:34 AM, Andrew Dunstan wrote: Is there an action item here? Is the documentation inadequate or inaccurate? If so, please make a suggestion for improved wording. I certainly expect the change to be covered in the release notes. You can check on the prominence given the item then and protest if you don't think it's adequate. You can ignore Alex and me till we work it out, if you like, and then we'll let you know directly if something needs to be changed/updated. Thanks, David -- 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 Fri, Feb 11, 2011 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote: OK, let me see if I can summarize what I think we've agreed to: CREATE syntax is extended to CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv] It strikes me that if you used the same options syntax here that we're already using for EXPLAIN and VACUUM and COPY, you wouldn't have to worry about adding keywords for current or future options. i.e. CREATE EXTENSION extname [ ( option [ , ... ] ) ] where option can be one of: SCHEMA blah VERSION blah FROM blah -- 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] Careful PL/Perl Release Not Required
On Feb 11, 2011, at 10:01 AM, Alex Hunsaker wrote: That *looks* like it is decoding the input string, which it is, but actually that will double utf8 encode your string. It does not seem to in this case because we are dealing with all ascii input. The trick here is its also telling perl to decode/treat the *output* string as utf8. Urp, this is a bit of a fib. The problem is actual in plperl not perl persay. Pre 9.1 we always fetched perls internal string *ignoring* the utf8 flag. So if you had octets that were utf8 things would work. In 9.0 in a utf-8 database, the utf8 flag is turned on. The utf8::decode($_[0]); uri_unescape($_[0]); happened to make the return string internally be utf8 and so it would only return 1 char. Thats what the op wanted and why it seemed to fix his problem. But thats actually a bug! utf8::decode($_[0]) should not have changed anything at all on the output side. It should still have returned 2 characters instead of 1. I don't understand where the bug is. If a string is encoded in utf-8 Perl will not treat it as such unless the utf-8 flag is set. Best, David -- 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 TYPE 2: skip already-provable no-work rewrites
Hi Robert, On Fri, Feb 11, 2011 at 10:27:11AM -0500, Robert Haas wrote: On Thu, Jan 27, 2011 at 2:48 PM, Noah Misch n...@leadboat.com wrote: Done as attached. ?This preserves compatibility with our current handling of composite type dependencies. ?The rest you've seen before. OK, I finally got back to this. Sorry for the delay. I still feel that it's possible to accomplish the same goal with less complexity. See what you think of the attached. It's a nice, clean patch. However, it achieves that by targeting a smaller goal. Specifically, it omits: 1) Test cases and DEBUG messages sufficient to facilitate them 2) Skip rewrite for T - constraint-free domain over T 3) Downgrade rewrite to scan for T - constrained domain over T Upon examination, it appeared to me that trying to make the AlteredTableInfo contain an enum indicating whether we were doing a scan, a rewrite, or nothing was requiring more code change than I could really justify. Offhand, I count 12 changed lines to introduce the enum. There may be other good reasons not to do it, but surely that wasn't it? What I ended up doing is replacing the 'bool new_changedoids' member with a 'bool rewrite' member. I'm pretty sure this is safe. The only reason we ever tested the new_changeoids member was to see whether we needed to do a rewrite; it wasn't used for anything else. The new member gets set either when we need to do a rewrite, or when a column type changes in a fashion that requires a rewrite. It's pretty easy to verify that this doesn't result in any behavior change, except for one corner case: currently, if you add or remove OIDs to/from a table and in the same ALTER TABLE command add a constraint that involves creating an index, such as a primary key, the new primary key index will get built, thrown away, and rebuilt a second time. With this change, we just build it once, which seems like an improvement, even though the case is vanishingly unlikely to ever happen in practice. This is fairly similar to the design in my first patch. The name was different (new_bits), and that patch had an extra bool for scan-only cases. I won't object to moving back to this, but I did find that your enum suggestion worked out significantly better. Even supposing we push off all scan-only cases to another patch, it would be good to have the tablecmds.c-internal representation of that in mind. No sense in simplifying a 12-line change to an 8-line change, only to redo it next patch. I also have to say that after playing with a little bit, I find the new debugging messages you added to be quite invaluable for understanding what's really going on. The old output told you basically nothing useful, even if you cranked it all the way up to DEBUG3. This is much better. Thanks. I added them solely to make automated testing possible, but they did turn out to have user value. I'll certainly make use of them when rewriting an inheritance tree of tables or a large table with many indexes. Hunk-specific comments follow, largely concerning documentation. I really, really don't want to get mired in a discussion of exact documentation text. In fact I think I'd rather hunt crocodiles barefoot, armed with nothing but ALTER TABLE ... DISABLE TRIGGER ALL than have such a discussion. But I'll articulate the rationale behind my original constructions, in case they include facts you did not consider when rewriting them. diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml index 9f02674..e3ceea8 100644 --- a/doc/src/sgml/ref/alter_table.sgml +++ b/doc/src/sgml/ref/alter_table.sgml @@ -766,9 +766,13 @@ ALTER TABLE replaceable class=PARAMETERname/replaceable para Adding a column with a non-null default or changing the type of an existing column will require the entire table and indexes to be rewritten. -This might take a significant amount of time for a large table; and it will -temporarily require double the disk space. Adding or removing a system -literaloid/ column likewise requires rewriting the entire table. +As an exception, if the old type and new types are binary compatible and In the documentation for CREATE CAST, we define binary compatible using Two types that are binary coercible both ways are also referred to as binary compatible. This feature does not require binary compatibility, merely a one-way binary coercion. Generally, though, I like where you're going. My version was accurate but obtuse. +the literalUSING/ clause does not change the column contents, the This is probably fine, but note that USING col || '' does not change the column contents, yet we won't optimize it. +table rewrite will be skipped, but the index rebuild is still required. This wrongly suggests that the rebuild mentioned earlier in the paragraph, affecting all indexes, will take place. It's a more-limited rebuild. +Adding or removing a
Re: [HACKERS] Range Types: -|- ops vs empty range
On Fri, February 11, 2011 19:02, Josh Berkus wrote: empty range = Zero length? If so, is it fixed at some point, but empty? '(x,x)'? '[x,x)'? Neither of the above should be possible, I think. The expression (x logically excludes the expression x). However, [x,x] would be valid, and would be a zero-length interval at the point x. Is it everything? '[-inf,+inf]'? No, that's everything which is a different concept. The above also ought to be possible, and overlap everything. Is it really meaningfully distinct from NULL? Yes. NULL means I don't know. If a range type IS NULL, then any operation performed with it ought to be NULL. Hence: IF y x, THEN: [x,x] [y,z) == TRUE [x,x] -|- (x,y] == TRUE NULL [y,z} IS NULL [-inf,+inf] [y,z) == FALSE I can imagine using all of these constructs in actual applications. In fact, I have *already* used [-inf,+inf] You say yes, but you don't mention empty range. Maybe we can indeed do without the concept of an empty-range?; it might simplify implementation as well as usage. I'm not decided, but I do find it hard to find a plausible use-case for it. -- 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 Fri, Feb 11, 2011 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a different default version name from what CREATE EXTENSION uses (unless Yes. I see that as a good feature to have. stable and support looks like good default aliases for me, but again, IANANS (native speaker). I'm not very happy with that at all, either as to the concept or the specific version-alias names. I don't think that CREATE and ALTER really need different default version targets. And those choices of names carry far too much baggage. Default is what they are as far as the system is concerned, but names like those imply a lot more. Anybody else have an opinion on this detail? I agree with you. -- 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] ALTER EXTENSION UPGRADE, v3
On Feb 11, 2011, at 10:06 AM, Tom Lane wrote: Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a different default version name from what CREATE EXTENSION uses (unless Yes. I see that as a good feature to have. stable and support looks like good default aliases for me, but again, IANANS (native speaker). I'm not very happy with that at all, either as to the concept or the specific version-alias names. I don't think that CREATE and ALTER really need different default version targets. And those choices of names carry far too much baggage. Default is what they are as far as the system is concerned, but names like those imply a lot more. Anybody else have an opinion on this detail? I think they should be the same. Anything else seems confusing and weird. Best, David -- 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] Range Types: -|- ops vs empty range
Josh Berkus j...@agliodbs.com wrote: I can imagine using all of these constructs in actual applications. But which of them, if any, is an empty range? -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] ALTER EXTENSION UPGRADE, v3
CREATE EXTENSION extname [ ( option [ , ... ] ) ] where option can be one of: SCHEMA blah VERSION blah FROM blah +1 This also means that users don't have to remember the specific ordering of the syntax, which is a big plus. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Range Types: empty ranges
Do we want empty ranges? The philosophy is that they are essentially the zero value of any range type. Like the number zero, it allows closure over operations that would otherwise return an error. For instance, the number zero is useful because you can do things like: f(x) = 5x + 3; And even if x is zero, the function is still defined, and even produces a more real number like 3. Sure, when you try to divide by zero, you have a problem, but otherwise it works. Similarly, intersection of ranges is somewhat analogous to multiplication of numbers. I have a feeling that there are a lot of applications that might use intersection in combination with other operators, like overlaps or contains. If we do allow empty ranges, I think it will be seamless in most of those situations because overlaps and contains are well-defined for empty ranges. But if we don't allow empty ranges, I suspect that it will cause some user surprise, because depending on the order of operations an empty range may be created (causing an error) or not. The cost, of course, is that not all operations are well-defined for empty ranges. I think those are mostly operators like those mentioned in the other thread: (strictly right of), (strictly left of), and -|- (adjacent); and perhaps and . These are probably used a little less frequently, and should probably not be used in a context where empty ranges are permitted (if they are, it's likely a mistake and an error should be thrown). My feeling is that we should let the operation proceed as far as it is well-defined, and no further; and I think that means empty ranges should be allowed. Thoughts? Do the benefits outweigh the costs? Regards, Jeff Davis -- 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
* Greg Smith (g...@2ndquadrant.com) wrote: -GNU libreadine is certainly never going to add an OpenSSL exemption I really wish they would, that's just them being obnoxious- it's already LGPL, after all.. -If the OpenSSL project was going to switch to a reasonable license, they'd have done it years ago aiui, the problem here is actually a former OpenSSL hacker who has no interest (and, in fact, a positive interest against) in changing the OpenSSL licensing. Most of the current OpenSSL hackers don't have an issue with the change (again, aiui). -There are many known and serious bugs/limitations in libedit relative to libreadline Yes, which makes it suck. :( -Adding GnuTLS support to PostgreSQL would require solving several code quality issues I'm curious about this, but I don't know that I've got time to dive into it and solve it. :/ Idealogically, I find the worst offendor here to be the OpenSSL license. From a license purity perspective I'd like to see their ridiculous requirements bypassed altogether by doing whatever is necessary to get GnuTLS support working. But pragmatically, fixing the bugs and adding features to libedit may be the easier route here. That suprises me.. There are a ton of tools which work with GnuTLS today, and hearing that it's got serious issues isn't good. :/ Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Debian readline/libedit breakage
On Fri, Feb 11, 2011 at 19:13, Stephen Frost sfr...@snowman.net wrote: * Greg Smith (g...@2ndquadrant.com) wrote: -Adding GnuTLS support to PostgreSQL would require solving several code quality issues I'm curious about this, but I don't know that I've got time to dive into it and solve it. :/ Yeah, I'm curious about that one as well. A lot has happened since this was last investigated, I believe. We may also have a problem in that libpq exposes OpenSSL structs, though. We actually return it as a void *, to make it possible to change, but there's no API in libpq to tell you what it is... -- 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] ALTER EXTENSION UPGRADE, v3
On Feb 11, 2011, at 9:35 AM, Tom Lane wrote: OK, let me see if I can summarize what I think we've agreed to: CREATE syntax is extended to CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv] If VERSION is not specified, v is taken from default_version in the control file, or fail if that's not given either. We create the pg_extension entry and then run the script extname-v.sql, or extname-oldv-v.sql if FROM is present. Sounds good. One nit: can't we call the line in the control file version rather than default_version? I've been thinking of the control file as describing a release of an extension, which of course has a version, not a default version. Oh, so what should oldv be to indicate creating from a legacy extension? ALTER syntax is extended with ALTER EXTENSION extname UPDATE [TO v] Again, if v is not specified, it is taken from default_version in the control file, or fail if that's not given either. Here we take oldv from the current pg_extension.extversion field, and then run the script extname-oldv-v.sql. We will add logic to find a chain of update scripts leading from oldv to v, in case that exact combination is not available in the extension's script directory. How do you determine the script directory? I've been using sql/ in my PGXN distributions. (NOTE: maybe in the CREATE ... FROM case, it would be a better idea to not do that search, but insist on finding exactly extname-oldv-v.sql? That would provide at least a little bit of extra protection against wrong FROM choice. Not sure how much it helps though.) Meh. Just goes to creating more work for the extension maintainer, who would then have to consider whether or not to make a bunch of omnibus upgrade scripts for any given release, just in case some user specified a FROM clause. Not thrilled with that. Seems to me either there's a chain or there isn't. Version identifiers will be ColId_or_Sconst in the grammar, ie, you can omit quotes if they're valid SQL identifiers. I'm not sure this helps with typical choices of version strings, but we might as well allow it. I guess it's good for purely numeric versions, like 0.25 or 9.0, but not for dotted-integer versions like 1.34.0. Version strings will have no hard-wired semantics except equality; we don't need a sorting rule. We must however forbid - in version strings, to avoid ambiguity as to whether a file name represents an install or upgrade script. (Note: - in extension names poses a hazard as well; not within a single extension, but for example foo-bar's install scripts could be confused with foo's upgrade scripts. However, I think we need not forbid - in extension names since this risk can be avoided by giving foo-bar its own script directory.) It also seems to me to be a good idea to forbid .. and directory separators in both types of names, because otherwise CREATE EXTENSION could be used to probe the file system. That's not really an issue right now, with use of the command being restricted to superusers anyway, but it's inevitable that we'll want to relax that restriction. Yeah. Might be worth considering using some other less common character as the delimiter. Maybe + or ^? not a big deal, though. I guess / should also be forbidden, eh? We will also add code to allow per-version control files extname-v.control in the script directory. After determining the version we plan to install or update to, we read the per-version control file if any, and let it override parameters from the primary control file. (This implies for example that a per-version control file's encoding setting would control all update scripts read while trying to get to that version. I'm not sure how useful that is --- given the chaining behavior, really you're going to have to use the same encoding throughout the extension's update files. Maybe better to disallow encoding in per-version control files?) +1. Best, David -- 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
Robert Haas robertmh...@gmail.com writes: On Fri, Feb 11, 2011 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote: OK, let me see if I can summarize what I think we've agreed to: CREATE syntax is extended to CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv] It strikes me that if you used the same options syntax here that we're already using for EXPLAIN and VACUUM and COPY, you wouldn't have to worry about adding keywords for current or future options. Hmm. You have a point, and there's some precedent for this in our other non-standard CREATE commands such as CREATE OPERATOR and CREATE AGGREGATE. On the other hand, we have no precedent for handling ALTER syntaxes that way. Also, I think most people feel that the CREATE OPERATOR and CREATE AGGREGATE syntaxes are ugly, not-very-SQL-ish beasts carried over from PostQUEL days. On the whole I have a weak preference for leaving it as above, but would readily yield to a consensus to do the other. One minor point is that I was planning to drop the opt_equals from the syntax --- it doesn't fit at all with the FROM case. 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
* Magnus Hagander (mag...@hagander.net) wrote: We may also have a problem in that libpq exposes OpenSSL structs, though. We actually return it as a void *, to make it possible to change, but there's no API in libpq to tell you what it is... Ugh, yeah, that probably wasn't the best decision in the world.. :( Stephen signature.asc Description: Digital signature
