Re: [HACKERS] Index AM change proposals, redux
* Proposed changes to allow amgetnext to return the actual index keys, allowing certain types of unindexable quals to be checked without having to fetch the heap entry. For example a LIKE condition could be fully checked against the index entry. In the extreme we could build tuples and push them up several nodes -- even including joins -- before fetching the rest of the attributes from the heap. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008, Brendan Jurd wrote: [Automatic e-mail notification] is trivial to configure in a real tracker. Less so for a wiki page, but it could still be accomplished with the careful application of script-fu. Anyone who is interested can sign up for e-mail notification whenever a specific wiki page is modified right now, that's a standard MediaWiki feature. If you wanted you could even sign up a mailing list as the entity being notified. That's not exactly what you had in mind I think, but it's close enough to be useful for now. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Bruce Momjian wrote: Fine with me, but I was hoping someone would come up with an idea that would reduce what I need to do, like perhaps a new vacuum cleaner. ;- Bruce et al., If you need a reasonably (modestly?) intelligent person to put to work helping, I am more than willing to work with you on what needs to be done. I have absolutely no idea if this offer is realistically of any value to you. As a comparative Pg newbie but longtime DBA/developer, it's not easy to find an entry point into this aspect of the Pg project. So, if you're willing to put up with the initial hassle of telling someone how to help you out, here's a new vacuum cleaner. Or at least feather duster. Paul -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Brendan Jurd [EMAIL PROTECTED] writes: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. Unfortunately that is the typical way to solve this. And it's awful. It's like the ubiquitous cryptic phone call in movies saying can't talk right now but there's something you should know. Meet me under the bridge Much much better are the systems like debbugs where you get the actual ticket by email. And can respond by email. And basically never need to visit the web interface unless you want to see the summarized data. Personally I would consider any system without at least these attributes to be unusable: a) Never sends an email without the full content it's notifying you of b) Never sends an email which can't be replied to normally -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication 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] Concurrent psql API
On Thu, 2008-04-10 at 05:03 +0930, Shane Ambler wrote:
I do think it is useful for more than typo's in the \join command. What
about a slip where you forget to \g the command. Or you start a query
that seems to be taking too long, background it and look into what is
happening. This would be more helpful to those that ssh into a machine
then run psql from there.
For interactive use in the above mentioned scenario you can use the
'screen' command and start as many psqls as needed ('man screen' to see
what it can do). I would probably always use screen instead of psql's
multisession capability in interactive use. I do want to instantly see
what is currently running, and a psql screen cluttered with multiple
results will not make that easier. Even a list method of what is running
will only help if it actually shows the complete SQL for all running
sessions and that will be a PITA if the SQLs are many and big. Multiple
screens are much better at that.
So from my POV scripting should be the main case for such a feature...
and there it would be welcome if it would be made easy to synchronize
the different sessions.
Cheers,
Csaba.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Gregory Stark wrote: Brendan Jurd [EMAIL PROTECTED] writes: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. Unfortunately that is the typical way to solve this. And it's awful. It's like the ubiquitous cryptic phone call in movies saying can't talk right now but there's something you should know. Meet me under the bridge Much much better are the systems like debbugs where you get the actual ticket by email. And can respond by email. And basically never need to visit the web interface unless you want to see the summarized data. Personally I would consider any system without at least these attributes to be unusable: a) Never sends an email without the full content it's notifying you of b) Never sends an email which can't be replied to normally this is something that out bugzilla demo installation is actually capable of (ie it can be entirely driven by and automatically track mail discussions as long as the mail somehow contains a bugid or get's one assigned in the course of the discussion). Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS][OT] Concurrent psql API
I find myself doing this frequently with any long-running command, but currently it's a PITA because I'd doing it at the shell level and firing up a new psql: more work than should be necessary, and psql sometimes gets confused when you resume it from the background in interactive mode (stops echoing characters, though maybe this has been fixed). I would recommend trying out the 'screen' utility (see my other post too). And here you find a nice .screenrc too which will show you a status bar of your active session, I find it super cool (and it's well commented if you don't like it as it is): http://home.insightbb.com/~bmsims1/Scripts/Screenrc.html The man page has all commands you need, the most used by me: Ctrl-a Ctrl-c - open a new session; Ctrl-a A - name the session 8will show up with that name in the status bar, note that the second key is a capital A not a); Ctrl-a Ctrl-a - switch to the last viewed session; Ctrl-a n - switch to the nth session, where n is a digit 0-9 I usually leave the screen sessions running end detach only the terminal, and then I can connect again to the already set up sessions using screen -R. It's a real time saver. It has many more facilities, and creating a new psql session is just Ctrl-a Ctrl-c and then type in psql... and you're good to go... I don't think you can beat that by a large margin with psql-intern commands (you still need to type in something extra), and you do have added benefits of clearly separated workflows and a nice overview of it. Cheers, Csaba. -- Sent 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 fast in PSQL, very slow using MS.NET driver
Thanks for the response. Below are the details: On Wed, 2008-04-09 at 18:33 +0530, Ashish Sharma wrote: Hi, Hi, all!! The setup in question includes PostGRESQL v8.2.4, Java based web servers and MS.NET based web servers. Following is the fuzzy situation: 1. Our SQL queries run very fast using PSQL (both, from the server as well as the client). 2. The Java app also retrieves the results very fast (of course, we are using Postgres JDBC driver). 3. But, the same SQL queries perform pathetically slow when called from .NET application. The driver being used is NPGSQL. What queries are you running? We are running normal SQLs and DMLs. Even simple queries like select * from... are showing the described behavior. What version of Npgsql? NPGSQL ver. 1.97.1.0 Are you using prepared statements? We have performance issues with prepared statements. If it is so, can you try without prepared statements? We are not you prepared statements. You can discuss this also in our forums: forums.npgsql.org The dotNet version we are using is 2.0, PostgreSQL 8.2.4 (on RHEL4) Appreciate the support. Regards, Ashish Sharma No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.11 - Release Date: 4/9/2008 12:00 AM -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Concurrent psql API
Csaba Nagy [EMAIL PROTECTED] writes: For interactive use in the above mentioned scenario you can use the 'screen' command and start as many psqls as needed Sure, or you could just start multiple xterms or emacs shell buffers (my preferred setup). But I'm sure there are people who would prefer C-z too. So from my POV scripting should be the main case for such a feature... and there it would be welcome if it would be made easy to synchronize the different sessions. I think it's the main case, that's why I didn't implement C-z at all. But I think we should keep it as a design consideration and not preclude it in the future. Hm. I had a thought though. Perhaps C-z should just immediately start a new connection. That would perhaps maintain the shell metaphor the way Tom was thinking where you're always at a usable prompt. That might suck if you're at a password-authenticated connection. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, Apr 10, 2008 at 1:07 PM, Gregory Stark [EMAIL PROTECTED] wrote: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. Unfortunately that is the typical way to solve this. And it's awful. It's like the ubiquitous cryptic phone call in movies saying can't talk right now but there's something you should know. Meet me under the bridge Yeah, it sucks, because people won't bother looking. It fails Tom's sniff test. (Although I can attest to having submitted a previously discussed patch to -patches and received *zero* feedback, even something like we're too busy getting 8.2 out, come back later). What's wrong with a patch submitter submitting a patch to a tracker, but then emailing the list for actual discussion? Hi there, I just upload patch #12345 which implements TODO item n, can people please have a look? I've done x, y and z, not sure about p and q. Then discussion still happens on-list which is a much better discussion medium, and the patch has a proper status page which the author can keep up to date with the latest version etc etc. If we feel the need to link patch status pages to the email archive, there's no harm in asking that the original email contain the bug number in the subject or something like that. That's going towards a more structured approach than a wiki, but I don't personally see that as a bad thing. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, Apr 10, 2008 at 3:03 PM, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. I presume you mean for -patches and not -hackers. Even so I reckon that would create vastly more noise than signal in the eventual tracker - part of the existing problem has been that wading through list archives is a pain for someone wanting to know the current status of a patch. I can't see the above helping that. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [JDBC] Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work
Is there any patch available for this one? I'm encountering troubles with some JDBC queries and I'd like to test it before asking some help on the JDBC list. Thanks. Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Setting a pre-existing index as a primary key
Tom Lane schrieb: Jonah H. Harris [EMAIL PROTECTED] writes: I've run into a couple cases now where it would be helpful to easily assign an already-existing unique index as a primary key. You need to present a more convincing use-case than this unsupported assertion. There's hardly any effective difference between a unique index + NOT NULL constraints and a declared primary key ... so what did you really need it for? In fact it seems to be necessary when connecting with ODBC, I had the problem a month ago, MsSQL will not work correctly with connected tables in a postgres database when there is no PK. NOT NULL and unique index is not enough. But I think it's overkill to add ALTER commands for this rare corner case, maybe it's enough to set indisprimary on the index? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Index AM change proposals, redux
* Proposed change to let both amgetnext and amgetmulti mark returned tuples as candidate matches, that is in need of rechecking of quals indexes). There seemed to be some possible marginal use for it in GIST indexes, but I'm not convinced that's a sufficient reason to complicate the APIs. This is good way to eliminate awful operation '@@@' without performance loss. * Proposed changes to allow amgetnext to return the actual index keys, allowing certain types of unindexable quals to be checked without having to fetch the heap entry. For example a LIKE condition could be fully checked against the index entry. Since certain types of indexes (GIN now, possibly hash in future) are incapable of doing this, there'd GiST too, because type of storage may be differ from type to be indexed. The same touches GIN too. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, Apr 10, 2008 at 3:41 PM, Gregory Stark [EMAIL PROTECTED] wrote: What's wrong with a patch submitter submitting a patch to a tracker, but then emailing the list for actual discussion? What's what we have today with the wiki. We don't need any special software to do that. It does require some patch queue maintainer(s) to make sure things get added or updated. Right, which is what a tracker gives you. A patch submitter can stick a patch up as WIP or whatever, and update it to ready-for-commit-review when they're ready, and it's easy to get a list of ready-to-review patches. If someone wants a patch to get reviewed in a commit fest, then it better have the latest version and an up-to-date status. I don't think getting submitters to follow the rules will be very hard - as someone pointed out it's trivial compared to the effort of writing a patch. The problem is more likely to be cleaning up old patches that people submit that never make it to prime time, but that's easier work for non-core people to help with. Anyway, I've said my piece and I don't want to discourage movement to a wiki - it seems a vast improvement in submitter-participation over the status quo. I just think there are even better tools for the job. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [JDBC] Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work
It's pretty easy to test. prepare the query and run explain analyze on the prepared statement. Dave On 10-Apr-08, at 5:47 AM, Thomas Burdairon wrote: Is there any patch available for this one? I'm encountering troubles with some JDBC queries and I'd like to test it before asking some help on the JDBC list. Thanks. Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Tom Dunstan wrote: On Thu, Apr 10, 2008 at 1:07 PM, Gregory Stark [EMAIL PROTECTED] wrote: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. Unfortunately that is the typical way to solve this. And it's awful. It's like the ubiquitous cryptic phone call in movies saying can't talk right now but there's something you should know. Meet me under the bridge Yeah, it sucks, because people won't bother looking. It fails Tom's sniff test. (Although I can attest to having submitted a previously discussed patch to -patches and received *zero* feedback, even something like we're too busy getting 8.2 out, come back later). What's wrong with a patch submitter submitting a patch to a tracker, but then emailing the list for actual discussion? Hi there, I just upload patch #12345 which implements TODO item n, can people please have a look? I've done x, y and z, not sure about p and q. Then discussion still happens on-list which is a much better discussion medium, and the patch has a proper status page which the author can keep up to date with the latest version etc etc. well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Tom Dunstan wrote: What's wrong with a patch submitter submitting a patch to a tracker, but then emailing the list for actual discussion? What's what we have today with the wiki. We don't need any special software to do that. It does require some patch queue maintainer(s) to make sure things get added or updated. well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. This requires an AI which passes the turing test. How do you determine what patch is related to and how it affects the status of that patch? This is precisely the work Bruce was doing previously and it's a lot of work. This is precisely what we're asking people to do on the wiki now. Bug/request trackers are great tools, but they're just tools. They don't replace actually having to do the work. Given the really trivial number of patches we're dealing with really just adding entries to a wiki page is a perfectly reasonable solution. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication 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] Commit fest queue
Tom Dunstan wrote: On Thu, Apr 10, 2008 at 3:03 PM, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. I presume you mean for -patches and not -hackers. Even so I reckon that would create vastly more noise than signal in the eventual tracker - part of the existing problem has been that wading through list archives is a pain for someone wanting to know the current status of a patch. I can't see the above helping that. well subscribe to both (so it can track discussions that move from -patches to -hackers) but only create tickets for stuff submitted to -patches. As for changing the status of a patch there will always need to be someone actually categorizing the patch - either by doing that in the tracker (or by adding an email command to one of the mails in the discussion or in the gui of whatever tool we use). The advantage would be that the information is fairly structured and most trackers have rather simply ways to condense the information down to a simple dashboard like thing (like what we have in the wiki) or provide an RSS feed or whatever. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Free Space Map data structure
PFC wrote: About the FSM : Would it be possible to add a flag marking pages where all tuples are visible to all transactions ? (kinda like frozen I think) Ah, the visibility map. That's another line of discussion. The current plan is to not tie that to the FSM, but implement it separately. There's some infrastructure changes that are needed for both, like the map forks (see recent FSM discussions), which is why we need to have a design for FSM as well before we start implementing the visibility map. It's definitely something I want to do for 8.4. Ahh, yes, yes, yes ;) yes ! Here's my rough plan: 1. Common map forks support 2. Rewrite FSM 3. Implement visibility map, to allow partial vacuums 4. Implement index-only scans, using the visibility map. Throwing another idea that is related to partial vacuums (perhaps ?): Consider a table that is often inserted (archive, forum posts, log, whatever), we want to CLUSTER it. In that case it would be beneficial to only cluster the tail of the table, where all the recently inserted rows are. Example : - Table is clustered. - Insert rows in random order, update some, delete some, etc, supposing inserts happen at the end - Table now looks like head:[clustered part with some holes] plus tail:[rows in random order] - As long as the tail fits in disk cache, the random order isn't a problem. - So, when the tail reaches a certain size : - Grab it, sort it by cluster order, write it again in the heap - Update the indexes in a manner similar to VACUUM (ie. bulk update) - Table now looks like head:[clustered part with some holes] plus tail:[clustered] This does not remove the holes in the head, but is this really a problem ? In this usage scenario, I don't think so. Regular CLUSTER could also be run, much less frequently than before, and it will also be much faster since the rows are approximately in-order already. This approach is complimentary to the auto-cluster approach where the index is asked where should I insert that row ? (this will be used to fill the holes). Auto-cluster will work well in tables that are updated very often. But starting from an empty table, or an already clustered table, or in a mostly-insert scenario, the index will have no idea where to put that row... The goodness of this approach is that - As long as the tail fits in RAM, sorting it is going to be very fast (unlike the current CLUSTER). - Bulk index updates will also be fast as long as the list of changes to apply to the index fits in memory. - Therefore it will block the table for much less time than good old CLUSTER. - Therefore it will get more use ;) How to make it non-locking ? - Doing something like this in pseudo SQL : INSERT INTO table SELECT * FROM (DELETE FROM table WHERE date last time we did this RETURNING *) ORDER BY cluster_columns; VACUUM; That is, take the tail of the table (as above), sort it, insert it back in big chunks, and mark the old rows as deleted just like a regular delete would have done. Then VACUUM. In this case you now have : head:[clustered part with some holes] + big hole + tail:[clustered rows] Is the big hole a problem ? Probably not, it will be marked as free space by VACUUM and used for new inserts. A week later we get this : head:[clustered part with some holes] + [rows in random order] + tail:[clustered rows] Repeating the process above will make the tail grow and the hole will stay more or less in the same place. Another way to do it is to use partitions : - archive table - current table Periodically the rows from current are transferred to the archive table and sorted in the process. Then current is truncated. This works, but it is blocking, and you have the overhead from partitioning... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Dumb Micro-Optimization
* Dumb Optimization #1: - Add executorFunc function pointer to struct PlanState - in ExecProcNode.c - ExecProcNode() : - upon first execution, set executorFunc to the function corresponding to node type - next calls use function pointer Effect : removes a switch (nodeTag(node)) which otherwise executes for every tuple returned by every node Gain : - 4% CPU time on SELECT sum(an integer column) FROM a table of one million rows - nil on selects returning few rows obviously -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Free Space Map data structure
Hannu Krosing wrote: On Wed, 2008-04-09 at 21:09 +0300, Heikki Linnakangas wrote: Hannu Krosing wrote: Saving 1 byte is an atomic op Unfortunately, it's not. Most if not all modern CPUs will perform one byte modification as load word + modify word + save word. Hmm, maybe we I should change my design to modify page free info and its parent together ? or what is word ? 2 bytes ? 4 bytes ? even 8 bytes ? It depends on architecture, I believe it's 4 bytes on 32-bit architectures and 8 bytes on 64-bit ones, typically. But we have to work on all of them. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake escribió: On Wed, 09 Apr 2008 23:01:30 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: I could see it with older submitters, who are used to just sending an email, but the new guys will go with whatever procedure is laid out for them *as long as* it is enforced ... Just as a note... email can be used as a submission procedure to a patch tracker. Yes, but it sucks, because either you create one for every email, or you have to give an explicit command to be captured by the system. I think the workflow over email is unstructured enough that there always needs to be a human to do some selective capturing of information. As soon as you get into things like creating templates which patch submitters are supposed to use, it's the about the same as having to go to the web interface to enter the patch. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] libpq type system 0.9a
Tom Lane wrote: Andrew Chernow [EMAIL PROTECTED] writes: What parts of PGconn/PGresult do you need to touch that aren't exposed already? Don't need direct access to PGconn at all. Oh, good, that makes things much easier. Shoot! Feels like you always miss something. The patch uses PGconn's PQExpBuffer to set errors on a conn. Currently, there is no access to this buffer other than PQerrorMessage. Is the below okay? extern PQExpBuffer *PQgetErrorBuffer(PGconn *conn); // OR PQsetErrorMessage(conn, errstr) -- this felt strange to me The expbuffer API is public, so managing the returned PQExpBuffer would not require any additional API calls. While I am on the subject of things I missed, the patch also uses pqSetResultError (mostly during PQgetf). We no longer need direct access to anything inside pg_result. However, we would need 3 new API calls that would dup a result, set field descs and add tuples to a result. Below are prototypes of what I have so far (small footprint for all 3, maybe 100-150 lines). /* numParameters, paramDescs, errFields, curBlock, * curOffset and spaceLeft are not assigned at all, * initialized to zero. errMsg is handled by * PQmakeEmptyPGresult. attDescs and tuples are not * duplicated, only allocated based on 'ntups' and * 'numAttributes'. The idea is to dup the result * but customize attDescs and tuples. */ PGresult *PQresultDup( PGconn *conn, PGresult *source, int ntups, int numAttributes); /* Only for results returned by PQresultDup. This * will set the field descs for 'field_num'. The * PGresAttDesc struct was not used to avoid * exposing it. */ int PQresultSetFieldDesc( PGresult *res, int field_num, const char *name, Oid tableid, int columnid, int format, Oid typid, int typlen, int typmod) /* Only for results returned by PQresultDup. This * will append a new tuple to res. A PGresAttValue * is allocated and put at index 'res-ntups'. This * is similar to pqAddTuple except that the tuples * table has been pre-allocated. In our case, ntups * and numAttributes are known when calling resultDup. */ int PQresultAddTuple( PGresult *res, char *value, int len); The above would allow an external app to dup a result and customize its rows and columns. Our patch uses this for arrays and composites. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.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] Separate psql commands from arguments
Am Samstag, 5. April 2008 schrieb Gregory Stark: Regardless of whether we go ahead with this (and I'm not fond of it primarily because I want \c to work), I think we would still be better off keeping the aliases in a separate namespace from psql commands and having an explicit command for calling them. The very point of this feature is to *not* have them in a separate name space. Shell aliases are commonly used for defining one- or two-letter abbreviations for other commands. No one would be using shell commands if they required you to prefix the call by mycommand or something like that. If you want to have a separate namespace, you could just write a function and call it, which uses about as many keystrokes as your proposed \query syntax. I also don't see any point in allowing aliases which call other psql commands. psql is not a particularly nice and well defined interface and it would just make it that much more complex and confusing. But other people do want to use it. If it is too confusing for you, don't use it. That's what's nice about this feature: If you don't use it, it doesn't affect you at all. I still see it much cleaner and much clearer for people reading the script Aliases are not primarily intended for scripts but for interactive use. No one wants to optimize away a few letters from a script. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Stefan Kaltenbrunner wrote: well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. This is (more or less) what the Tracman system proposed by Josh Drake does -- and it's awful IMHO. Amusingly, it's also more or less the same thing that debbugs does, which IMHO is really good. The main difference (again IMHO) is that Tracman tries to stuff the info in Trac comments, so it has to forcefully extract things from the email with rather poor results; whereas debbugs uses the mbox itself as the definite storage. Note that neither are really subscribed to the lists; rather they are some sort of gatekeepers, which process the email *before* they get to the list. (Actually, AFAIK in debbugs there is no actual mail list -- it's all mainly about appropriate CC's.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ 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] Commit fest queue
Tom Lane escribió: Obviously there are virtues on both sides of this, which is why I think we need both mechanisms. The simplest way to integrate them AFAICS is to use the tracker as an index on the email traffic. Agreed. -- Alvaro Herrerahttp://www.CommandPrompt.com/ 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] [SQL] pl/PgSQL, variable names in NEW
Martin Edlman wrote: | I don't want to rewrite whole trigger to plPerl as I would have to use | DBD-PgSPI. | | Huh? Certainly not -- there are functions in PL/Perl for this. See | spi_exec_query in | http://www.postgresql.org/docs/8.3/static/plperl-database.html Oh, I see. I have read the doc ...can be done via the function spi_exec_query described below, or via an experimental module DBD::PgSPI..., but missed the OR and thought that DBD::PgSPI is mandatory. Yeah, that's a bit confusing. I don't know why we have a mention of DBD::PgSPI on the plperl manual at all. Is there anything it can do that can't be done with PL/Perl native calls? Question for plperl hackers: Should we remove the mention of DBD::PgSPI from the PL/Perl manual? -- Alvaro Herrerahttp://www.CommandPrompt.com/ 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] Separate psql commands from arguments
Peter Eisentraut [EMAIL PROTECTED] writes: But other people do want to use it. If it is too confusing for you, don't use it. That's what's nice about this feature: If you don't use it, it doesn't affect you at all. Ah but I would use it. In particular the query I found myself writing *all* the time over and over again in Oracle was: select count(*),n from (select count(*) as n from tab group by col) group by n I can type it out now from finger-memory without even thinking about it. I would have killed for a macro facility like this where I could just do \query dist users city and get the frequency distribution of cities in the users table. I don't think \dist users city is really much of a savings and I think it would be a huge source of confusion that it's unrelated to the \di \ds and \dt commands. And I might well not know about those commands and define a \di alias myself, only to try using \di later. Or worse, define a \dx command and have it fail mysteriously in Pg 8.4. Also, people do share stuff, even (or especially!) cute short cuts like this. In the worst case witness Redhat's insistence on putting those damn aliases in the standard dotfiles for example. And plenty of sites have aliases in their root dotfiles which are part of their site operating procedures. Picture having to explain how to use psql to new hires including the site-specific aliases which you've built up over time when some of those aliases conflict or have similar names to built-in commands. A new user has no way to figure out which ones will do what type of action. Sure in the majority of cases it doesn't really matter how awkwardly intermingled with the \commands the interface is. But it doesn't make much sense to design around the cases where the design doesn't matter -- that way lies, uhm, other databases. Let's keep in mind when designing the feature the most long-term use where the design matters most rather than the case where it matters least. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Alvaro Herrera wrote: Stefan Kaltenbrunner wrote: well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. This is (more or less) what the Tracman system proposed by Josh Drake does -- and it's awful IMHO. Amusingly, it's also more or less the same thing that debbugs does, which IMHO is really good. The main difference (again IMHO) is that Tracman tries to stuff the info in Trac comments, so it has to forcefully extract things from the email with rather poor results; whereas debbugs uses the mbox itself as the definite storage. Note that neither are really subscribed to the lists; rather they are some sort of gatekeepers, which process the email *before* they get to the list. (Actually, AFAIK in debbugs there is no actual mail list -- it's all mainly about appropriate CC's.) The issue frankly is not tracker features. The issue is who is going to maintain it, doing pruning and triage as necessary. No tracker looks after itself. Everybody has their favorite tracker (editor, OS, SCM, ...) ... we can have endless fun debating them backwards and forwards and never reach a conclusion, just as we do fairly regularly. The consensus last year among a group of us who examined a number of tracker systems was, IIRC, that Bugzilla had the best combination of features that people had requested. (And it does have some email interaction). Stefan Kaltenbrunner did some work on putting up a test instance and played with integrating it with the Postgres bug system - I forget how far exactly he got. My understanding BTW is that debbugs is very specifically tailored to Debian needs, and is not suitable as a general purpose tracker system. And no other OSS project that we could find uses it. So, before we even look at it again I at least would want concrete proof that these things have changed. (Perhaps Alvaro has forgotten those discussions ;-) ) (And yes, Trac sucks) 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] [PATCHES] libpq type system 0.9a
Andrew Chernow [EMAIL PROTECTED] writes: Shoot! Feels like you always miss something. The patch uses PGconn's PQExpBuffer to set errors on a conn. Currently, there is no access to this buffer other than PQerrorMessage. Is the below okay? Surely you would just provide a function to get pqtypes errors separate from libpq errors? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS 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] Commit fest queue
Gregory Stark wrote: Bug/request trackers are great tools, but they're just tools. They don't replace actually having to do the work. Given the really trivial number of patches we're dealing with really just adding entries to a wiki page is a perfectly reasonable solution. +1 -- Alvaro Herrerahttp://www.CommandPrompt.com/ 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] Commit fest queue
Andrew Dunstan wrote: The consensus last year among a group of us who examined a number of tracker systems was, IIRC, that Bugzilla had the best combination of features that people had requested. (And it does have some email interaction). Stefan Kaltenbrunner did some work on putting up a test instance and played with integrating it with the Postgres bug system - I forget how far exactly he got. I tested Stefan's installation a bit. The main conclusion I got from it was that the email interface was a late kludge. Even if it were improved to remove the bugs, the fact remains that the emails themselves are not the main storage. My understanding BTW is that debbugs is very specifically tailored to Debian needs, and is not suitable as a general purpose tracker system. And no other OSS project that we could find uses it. So, before we even look at it again I at least would want concrete proof that these things have changed. (Perhaps Alvaro has forgotten those discussions ;-) ) I haven't forgotten them :-) but from my PoV, the only important argument against debbugs is that the code is not readily available. The fact that it is tailored to Debian does not seem so much of a problem to me -- I'm sure we could easily lure it into doing our thing. IIRC Peter Eisentraut said he was going to talk to the guys in charge of debbugs at FOSDEM, or something like that. I wonder if it materialized, and whether something came out of that? -- Alvaro Herrerahttp://www.CommandPrompt.com/ 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] [PATCHES] libpq type system 0.9a
Gregory Stark wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Shoot! Feels like you always miss something.
The patch uses PGconn's PQExpBuffer to set errors on a conn. Currently, there
is no access to this buffer other than PQerrorMessage. Is the below okay?
Surely you would just provide a function to get pqtypes errors separate from
libpq errors?
That's extremely akward. Consider the below.
int getvalues(PGresult *res, int *x, char **t)
{
return PQgetf(res, get the int and text);
}
if(getvalues(res, x, t))
printf(%s\n, PQresultErrorMessage(res));
How would the caller of getvalues know whether the error was generated
by a libpqtypes API call or by a libpq API call (like PQgetvalue)?
PQgetf should behave exactely as PQgetvalue does, in regards to errors.
Same holds true for PGconn. Normally, you are using PQputf which sets
the error in PQparamErrorMessage. Then there is PQparamCreate(conn) or
PQparamExec(conn, param, ...) and friends? PQparamExec calls
PQexecParams internally which can return NULL, setting an error message
inside PGconn. We felt our light-weight wrappers should be consistent
in behavior. If you get a NULL PGresult for a return value,
PQerrorMessage should be checked.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.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] Commit fest queue
Alvaro Herrera wrote: Andrew Dunstan wrote: The consensus last year among a group of us who examined a number of tracker systems was, IIRC, that Bugzilla had the best combination of features that people had requested. (And it does have some email interaction). Stefan Kaltenbrunner did some work on putting up a test instance and played with integrating it with the Postgres bug system - I forget how far exactly he got. I tested Stefan's installation a bit. The main conclusion I got from it was that the email interface was a late kludge. Even if it were improved to remove the bugs, the fact remains that the emails themselves are not the main storage. True - but that might not actually be a problem as long as we have a way to correlate the comments there easily (and automatically) to the threads and the individual mails - and yes the emailinterface might need some work but well work will be required in one for or another anyway. My understanding BTW is that debbugs is very specifically tailored to Debian needs, and is not suitable as a general purpose tracker system. And no other OSS project that we could find uses it. So, before we even look at it again I at least would want concrete proof that these things have changed. (Perhaps Alvaro has forgotten those discussions ;-) ) I haven't forgotten them :-) but from my PoV, the only important argument against debbugs is that the code is not readily available. The fact that it is tailored to Debian does not seem so much of a problem to me -- I'm sure we could easily lure it into doing our thing. and keep maintaining it on our own forever ? IIRC Peter Eisentraut said he was going to talk to the guys in charge of debbugs at FOSDEM, or something like that. I wonder if it materialized, and whether something came out of that? fairly sure petere missed FOSDEM :-) Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Andrew Dunstan wrote: Alvaro Herrera wrote: Stefan Kaltenbrunner wrote: well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. This is (more or less) what the Tracman system proposed by Josh Drake does -- and it's awful IMHO. Amusingly, it's also more or less the same thing that debbugs does, which IMHO is really good. The main difference (again IMHO) is that Tracman tries to stuff the info in Trac comments, so it has to forcefully extract things from the email with rather poor results; whereas debbugs uses the mbox itself as the definite storage. Note that neither are really subscribed to the lists; rather they are some sort of gatekeepers, which process the email *before* they get to the list. (Actually, AFAIK in debbugs there is no actual mail list -- it's all mainly about appropriate CC's.) The issue frankly is not tracker features. The issue is who is going to maintain it, doing pruning and triage as necessary. No tracker looks after itself. heh very true ... Everybody has their favorite tracker (editor, OS, SCM, ...) ... we can have endless fun debating them backwards and forwards and never reach a conclusion, just as we do fairly regularly. The consensus last year among a group of us who examined a number of tracker systems was, IIRC, that Bugzilla had the best combination of features that people had requested. (And it does have some email interaction). Stefan Kaltenbrunner did some work on putting up a test instance and played with integrating it with the Postgres bug system - I forget how far exactly he got. the setup is more or less complete and the integration part was with the community login system (same we have now for wiki.postgresql.org) by adding a postgresql authentication backend as well as some experimental modifications to the email_in.pl script to enable autocreation of bugs from email. I did't push it further (or put it to a silent trial on say -bugs which is way less complex than -patches but might give us some ideas on the usability anyway) because I was fairly busy at the time and could not probably support it on a larger scale and it is far from clear that we actually want something like that. My understanding BTW is that debbugs is very specifically tailored to Debian needs, and is not suitable as a general purpose tracker system. And no other OSS project that we could find uses it. So, before we even look at it again I at least would want concrete proof that these things have changed. (Perhaps Alvaro has forgotten those discussions ;-) ) yeah that is my impression as well. (And yes, Trac sucks) +1 Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 09:29:10 -0400 Andrew Dunstan [EMAIL PROTECTED] wrote: The issue frankly is not tracker features. The issue is who is going to maintain it, doing pruning and triage as necessary. No tracker looks after itself. If you provide a reasonable interface to management (which we don't have now) you will get people to help. I can do pruning, triage and follow up so can a *lot* of other people that aren't C hackers. that these things have changed. (Perhaps Alvaro has forgotten those discussions ;-) ) (And yes, Trac sucks) You do realize that they *all* suck right? I have never seen *one* system that I have said, ooh ooh can I have my ice cream now, I have already had my cake. Trac is the only one that I have found that is anywhere near reasonable in its management of simplicity and features. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 09:36:23 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: Gregory Stark wrote: Bug/request trackers are great tools, but they're just tools. They don't replace actually having to do the work. Given the really trivial number of patches we're dealing with really just adding entries to a wiki page is a perfectly reasonable solution. I don't think so because it really isn't a change from what we have now. There isn't much difference from having a wiki page versus just having conversations on the patch list and moving email around. We really need to be looking at the bigger picture here. The more ridiculous our patch management and feedback procedures are, the more likely we won't get patches from new people (there are a whole of other reasons too, but for this context). Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MSVC build broken with perl 5.10
Andrew Dunstan wrote:
Magnus Hagander wrote:
I just tried the MSVC build on a system with ActiveState Perl 5.10,
and it doesn't work. Some quick debugging before I downgraded to
5.8 showed that this regexp in Project.pm line 262:
my $replace_re =
qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*: )?\$(\([^\)]+\))\/(.*)\/[^\/]+$};
matches things properly using Perl 5.8 in for example
src/bin/initdb/Makefile (matches a total of around 10 Makefiles),
but in 5.10 it simply does not match anything...
Any perl guru out there who can comment on why? ;-)
Perhaps you would like to comment it using the x format, so that it
doesn't just look like white noise.
That would be a good idea, no? ;-) I have no idea what you mean with
using the x format, though, but I agree in general that the
white-noise format is not a good idea...
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake wrote: On Thu, 10 Apr 2008 09:36:23 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: Gregory Stark wrote: Bug/request trackers are great tools, but they're just tools. They don't replace actually having to do the work. Given the really trivial number of patches we're dealing with really just adding entries to a wiki page is a perfectly reasonable solution. I don't think so because it really isn't a change from what we have now. There isn't much difference from having a wiki page versus just having conversations on the patch list and moving email around. If you don't think it's a change, I claim you haven't used either :-P -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Separate psql commands from arguments
Gregory Stark escribió: Ah but I would use it. In particular the query I found myself writing *all* the time over and over again in Oracle was: select count(*),n from (select count(*) as n from tab group by col) group by n I can type it out now from finger-memory without even thinking about it. I would have killed for a macro facility like this where I could just do \query dist users city If we separated the namespace with something that involved a bit less typing, would you use it? Say \-dist users city (Or some other char instead of hyphen) The point is that you don't mix it with other \ commands, and as soon as you put \- you can already press TAB to get a list of aliases. So it _is_ useful both for interactive use and script use. \query dist is good for scripts but bad for interactive: too much extra typing. Whereas \dist is only relatively good for interactive (no good support for tab completion), and not any better for scripting. -- Alvaro Herrerahttp://www.CommandPrompt.com/ 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] Commit fest queue
Am Donnerstag, 10. April 2008 schrieb Tom Dunstan: Even so I reckon that would create vastly more noise than signal in the eventual tracker - part of the existing problem has been that wading through list archives is a pain for someone wanting to know the current status of a patch. I can't see the above helping that. We don't actually receive that many new patches or bugs. One or two people going through the tracker once a week and closing the closed issues would be quite doable. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GiST opclass and varlena
I guess I'll keep talking to myself, but... Le mercredi 02 avril 2008, Dimitri Fontaine a écrit : My previous tests were only done with REL8_2_STABLE cvs branch, I just redone some tests with REL8_3_STABLE and got no error. The index is still buggy, in the sense some requests returns different results with or without it (enable_seqscan). It turned around the error was related to the definition of my gpr_penalty() function, which I wanted to expose as the GiST internal and a SQL callable one too (for debugging and tests purpose). I forgot to define the internal one in the prefix.c side of things, got no complaint whatsover (nor at compile time neither at prefix.sql installation time) but garbage as data in __pr_penalty() function (not respecting GiST calling conventions). I guess the 8.2 invalid memory alloc request size ERROR was related to the same pilot error, as it's now gone too. Now this problem is overcome and the codes allows me again to create index and use them in queries both in 8.2 and 8.3, but there's still DEBUG ongoing. I've augmented the README for interested people to have more information: http://prefix.projects.postgresql.org/README.html Regards, -- dim signature.asc Description: This is a digitally signed message part.
Re: [HACKERS] Commit fest queue
Am Donnerstag, 10. April 2008 schrieb Andrew Dunstan: The issue frankly is not tracker features. The issue is who is going to maintain it, doing pruning and triage as necessary. I'll do it. Now just give me one I can maintain. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Concurrent psql API
So, Greg, after all this feedback, are you going to rework the patch? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 10:15:29 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: I don't think so because it really isn't a change from what we have now. There isn't much difference from having a wiki page versus just having conversations on the patch list and moving email around. If you don't think it's a change, I claim you haven't used either :-P I admit, I didn't use the wiki page because I got tired of trying to figure out which page, or list I should be looking at. I was still get js-kit replies from Bruces pages this week. Someone, anyone should be able to look exactly one place for the information required to process a patch. Of course we still have cvs etc.. but nobody on this list or new to the community should ever say to themselves, Which page am I supposed to go to? What list am I supposed to reply to now that I have feedback? Oh, I am supposed to go over to this wiki? Then what? You should be able to say, Hey here is the history of the patch for materialized views and then 30 hours later say, Phew large patch but here is my feedback Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Am Donnerstag, 10. April 2008 schrieb Stefan Kaltenbrunner: the setup is more or less complete and the integration part was with the community login system (same we have now for wiki.postgresql.org) by adding a postgresql authentication backend as well as some experimental modifications to the email_in.pl script to enable autocreation of bugs from email. I did't push it further (or put it to a silent trial on say -bugs which is way less complex than -patches but might give us some ideas on the usability anyway) because I was fairly busy at the time and could not probably support it on a larger scale and it is far from clear that we actually want something like that. I would like to continue in that direction. Collect all -bugs and -patches threads as tracker items. I'll volunteer to close the closed ones. If someone has another tracking system to propose, I'd suggest checking it against http://wiki.postgresql.org/wiki/TrackerDiscussion. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake wrote: On Thu, 10 Apr 2008 10:15:29 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: I don't think so because it really isn't a change from what we have now. There isn't much difference from having a wiki page versus just having conversations on the patch list and moving email around. If you don't think it's a change, I claim you haven't used either :-P I admit, I didn't use the wiki page because I got tired of trying to figure out which page, or list I should be looking at. I was still get js-kit replies from Bruces pages this week. I don't know what you're talking about. There are two wiki pages, one for the March commitfest and one for May. How can you be confused on which one are you supposed to look at? http://wiki.postgresql.org/wiki/CommitFest:March http://wiki.postgresql.org/wiki/CommitFest:May -- Alvaro Herrerahttp://www.CommandPrompt.com/ 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] Commit fest queue
On Thu, 10 Apr 2008 10:28:55 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: I admit, I didn't use the wiki page because I got tired of trying to figure out which page, or list I should be looking at. I was still get js-kit replies from Bruces pages this week. I don't know what you're talking about. There are two wiki pages, one for the March commitfest and one for May. How can you be confused on which one are you supposed to look at? http://wiki.postgresql.org/wiki/CommitFest:March http://wiki.postgresql.org/wiki/CommitFest:May Am I supposed to look at the wiki page or bruce pages, or am I supposed to replying on the list about something. All of which happen during this fest. I have no doubt that it is obvious to you. It certainly wasn't to me. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Am Donnerstag, 10. April 2008 schrieb Tom Lane: Another is that the email list provides a push mechanism for putting the proposed patch under the noses of a bunch of people, a few of whom will hopefully take a sniff ;-). A tracker is very much more of a pull scenario where someone has to actively go looking for pending/proposed changes. In my mind the pull mechanism is exactly one of the major features I would expect from a proper tracking system, so I can pull and work on the issues that affect me at a time when it is convenient for me, instead of at the time when the push happens. -- Sent 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] pl/PgSQL, variable names in NEW
Alvaro Herrera [EMAIL PROTECTED] writes: Question for plperl hackers: Should we remove the mention of DBD::PgSPI from the PL/Perl manual? It seems like a reasonable suggestion to me, since perl database users probably already know DBD and don't have to learn something new if they go that way. Possibly the text should be reworded, with the mention of DBD::PgSPI put somewhere else or stuck into a note or something. 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] Concurrent psql API
Alvaro Herrera [EMAIL PROTECTED] writes: So, Greg, after all this feedback, are you going to rework the patch? I'm a bit busy now but yes, eventually. I had in mind that it would probably make sense to start over, stealing code as appropriate. The main thing is that the logic is a bit twisted now since I originally had it as a prefix command you gave before issuing the sql. As a postfix command, \g, the logic could be a bit simpler. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication 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] Commit fest queue
On Thu, 10 Apr 2008 07:30:32 -0700 Joshua D. Drake [EMAIL PROTECTED] wrote: I don't know what you're talking about. There are two wiki pages, one for the March commitfest and one for May. How can you be confused on which one are you supposed to look at? http://wiki.postgresql.org/wiki/CommitFest:March http://wiki.postgresql.org/wiki/CommitFest:May Am I supposed to look at the wiki page or bruce pages, or am I supposed to replying on the list about something. All of which happen during this fest. O.k. after reviewing it seems the wiki stuff came in a bit late but even looking at the wiki... this is the problem I see. I go to the wiki page: http://wiki.postgresql.org/wiki/CommitFest:May I click the patch for EXPLAIN progress info: http://archives.postgresql.org/message-id/[EMAIL PROTECTED] The message comes up. Granted... very, very cool that this is all linked, so +1. But now what? * Where do I comment? * Where do I submit my updated patch that fixes a small syntax error that Greg made? * How do I track it in the future? * Do I go to the wiki page again? * If I go to the wiki page again and click on the patch is it going to take me right back to the archive page? * If it takes me right back to the archives page, am I going to be plowing through 50 comments in the web archive format (which is laborious and inefficient for this sort of thing) in order to find the next relevant email (which would be the first one after I submitted my update to the patch?) * After I submitted my comments where do I go? * Do I submit them to -patches? * Or hackers? * What about cross threads? * Am I going to have to do that for every single patch I review? And in looking at this further, if I look at the Column Level privelages patch on the wiki, the archive page goes to a -hackers email. http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php * Do I now respond to the hackers list? Lastly, how is this sustainable? I don't see anything that is reducing Bruce's workload. (for example) Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [DOCS] [HACKERS] [SQL] pl/PgSQL, variable names in NEW
On Thu, 10 Apr 2008 10:45:25 -0400 Tom Lane [EMAIL PROTECTED] wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Question for plperl hackers: Should we remove the mention of DBD::PgSPI from the PL/Perl manual? It seems like a reasonable suggestion to me, since perl database users probably already know DBD and don't have to learn something new if they go that way. Possibly the text should be reworded, with the mention of DBD::PgSPI put somewhere else or stuck into a note or something. From what I can see on CPAN (unless I am missing something) DBD::PgSPI hasn't been updated since 2004 and is at version 0.2. http://www.cpan.org/modules/by-module/DBD/ I think it can safely be removed in entirety from our manuals. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MSVC build broken with perl 5.10
On Thu, Apr 10, 2008 at 04:12:56PM +0200, Magnus Hagander wrote:
my $replace_re =
qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*: )?\$(\([^\)]+\))\/(.*)\/[^\/]+$};
Perhaps you would like to comment it using the x format, so that it
doesn't just look like white noise.
That would be a good idea, no? ;-) I have no idea what you mean with
using the x format, though, but I agree in general that the
white-noise format is not a good idea...
Using x format modifier means you can put comments and whitespace in your
regex, like:
my $replace_re = qr{^([^:\n\$]+\.c)# This matches the filename in $1
\s*:\s*(?:%\s*:\ )? # somethig with a %-sign
...etc...
}x;
Check the perlre manpage for more info.
Have a nice day,
--
Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Please line up in a tree and maintain the heap invariant while
boarding. Thank you for flying nlogn airlines.
signature.asc
Description: Digital signature
Re: [HACKERS] Commit fest queue
Peter Eisentraut [EMAIL PROTECTED] writes: Am Donnerstag, 10. April 2008 schrieb Tom Lane: Another is that the email list provides a push mechanism for putting the proposed patch under the noses of a bunch of people, a few of whom will hopefully take a sniff ;-). A tracker is very much more of a pull scenario where someone has to actively go looking for pending/proposed changes. In my mind the pull mechanism is exactly one of the major features I would expect from a proper tracking system, so I can pull and work on the issues that affect me at a time when it is convenient for me, instead of at the time when the push happens. Of course. The point is we need both, since each way scratches a different itch. Also, I'm quite hesitant to abandon a working process --- our email-based procedures have served the project pretty well over the past ten-plus years, else we'd not be here having this discussion. So, at least in the beginning, I want to layer any tracking process over what we already do, not make a big change for unproven results. 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: [DOCS] [HACKERS] [SQL] pl/PgSQL, variable names in NEW
Joshua D. Drake wrote: On Thu, 10 Apr 2008 10:45:25 -0400 Tom Lane [EMAIL PROTECTED] wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Question for plperl hackers: Should we remove the mention of DBD::PgSPI from the PL/Perl manual? It seems like a reasonable suggestion to me, since perl database users probably already know DBD and don't have to learn something new if they go that way. Possibly the text should be reworded, with the mention of DBD::PgSPI put somewhere else or stuck into a note or something. From what I can see on CPAN (unless I am missing something) DBD::PgSPI hasn't been updated since 2004 and is at version 0.2. http://www.cpan.org/modules/by-module/DBD/ I think it can safely be removed in entirety from our manuals. +1. It's also GNU licensed, so we can't include it. A clean room BSD licensed implementation would be a nice addition, but it really doesn't buy you much in functionality that you don't already have. 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] [PATCHES] libpq type system 0.9a
Andrew Chernow [EMAIL PROTECTED] writes: How would the caller of getvalues know whether the error was generated by a libpqtypes API call or by a libpq API call (like PQgetvalue)? PQgetf should behave exactely as PQgetvalue does, in regards to errors. Hm. Well I was thinking of errors from database operations rather than things like PQgetvalue. I suppose we have to decide whether pqtypes is a wrapper around libpq in which case your functions would have to take the libpq error and copy it into your error state or an additional set of functions which are really part of appendage of libpq -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres 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: [DOCS] [HACKERS] [SQL] pl/PgSQL, variable names in NEW
Joshua D. Drake [EMAIL PROTECTED] writes: From what I can see on CPAN (unless I am missing something) DBD::PgSPI hasn't been updated since 2004 and is at version 0.2. Oh, if it's not a live project then that changes things entirely. +1 for just dropping the mention. 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] Commit fest queue
Greg Smith wrote: Apache also pushes everything through bugzilla: http://httpd.apache.org/dev/patches.html The interesting quote there is: Traditionally, patches have been submitted on the developer's mailing list as well as through the bug database. Unfortunately, this has made it hard to easily track the patches. And without being able to easily track them, too many of them have been ignored. Patches must now be submitted through the bug database... The thing that will obviously go away if this project were to switch to such a model is that right now, there are lots of ideas that go by that would never be submitted as patches like that. But Bruce snags them and turns them into todo items and such rather than letting the idea just get lost in the archives. I assume you also read this Apache heading: What if my patch gets ignored? Because Apache has only a small number of volunteer developers, and these developers are often very busy, it is possible that your patch will not receive any immediate feedback. ... Be persistent but polite. Post to the developers list pointing out your patch and why you feel it is important. Feel free to do this about once a week and continue until you get a response. This indicates to me that their patch system doesn't work too well in practice. ;-) Perhaps Apache is a more mature technology or more poorly managed. I can't imagine us requring an FAQ entry like that about ignored patches. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
* Bruce Momjian [EMAIL PROTECTED] [080410 11:06]: I assume you also read this Apache heading: What if my patch gets ignored? Because Apache has only a small number of volunteer developers, and these developers are often very busy, it is possible that your patch will not receive any immediate feedback. ... Be persistent but polite. Post to the developers list pointing out your patch and why you feel it is important. Feel free to do this about once a week and continue until you get a response. This indicates to me that their patch system doesn't work too well in practice. ;-) Perhaps Apache is a more mature technology or more poorly managed. I can't imagine us requring an FAQ entry like that about ignored patches. Well, currently *you* are the reason we don't ;-) a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] libpq type system 0.9a
On Thu, Apr 10, 2008 at 10:56 AM, Gregory Stark [EMAIL PROTECTED] wrote: Andrew Chernow [EMAIL PROTECTED] writes: How would the caller of getvalues know whether the error was generated by a libpqtypes API call or by a libpq API call (like PQgetvalue)? PQgetf should behave exactely as PQgetvalue does, in regards to errors. Hm. Well I was thinking of errors from database operations rather than things like PQgetvalue. I suppose we have to decide whether pqtypes is a wrapper around libpq in which case your functions would have to take the libpq error and copy it into your error state or an additional set of functions which are really part of appendage of libpq We see libpq types to be simply extending the api with more functions. We really only introduce new error handling with the PGparam struct that is following the same conventions that exist currently. The separation of libpqtypes out of libpq into a new library is an architectural change for organization purposes. We are not defining a new api or wrapping an existing one for new functionality (which is the same thing imo). With that in mind, libpq's error system is object based, not library based. Thee three objects that set errors are result, conn, (and now), param. In libpq terms there is no global error. (no errno, getlasterror, etc). So, if I understand you correctly, we see libpqtypes is an appendage in your terms...were you thinking along different lines? Consider that we don't reproduce all the things libpq offers, we share the same objects, etc. (In fact, we went though some acrobatics to introduce as little new behavior as possible). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Warning - my development views and experiences are highly e-mail dependant (i.e. linux-kernel style dependant). So if you don't like email, you probably shouldn't read my response below. * Joshua D. Drake [EMAIL PROTECTED] [080410 10:48]: I click the patch for EXPLAIN progress info: http://archives.postgresql.org/message-id/[EMAIL PROTECTED] The message comes up. Granted... very, very cool that this is all linked, so +1. But now what? I think the point is that the PostgreSQL development happens via e-mail and on mailing lists. So the goal is to point you to the mail, so you can join in on the development (i.e. by mail on the mailing lists). Maybe the archives should offer a way to download the raw message? In addition to all the normal stuff people want from archives that mhonarc seems to do poorly ;-) * Where do I comment? In your mail program. * Where do I submit my updated patch that fixes a small syntax error that Greg made? Again - by mail, to -patches. And hopefully someone (the patch author, team of people, not Bruce) would update the wiki/tracker to say the patch has been revised, version X is $MSGID * How do I track it in the future? * Do I go to the wiki page again? Well, only if you want to pull the last status (i.e. someone else, not you may have updated it, and you haven't set yourself to be notified on changes). But again, since it's by email, you already have it all in your inbox, right? * If I go to the wiki page again and click on the patch is it going to take me right back to the archive page? Only if the wiki/tracker *hasn't* been updated. * If it takes me right back to the archives page, am I going to be plowing through 50 comments in the web archive format (which is laborious and inefficient for this sort of thing) in order to find the next relevant email (which would be the first one after I submitted my update to the patch?) Uh, don't you read your e-mail already? Any comment/discussions on the patch would have had you in the reply-to chain. All nicely threaded in your mail reader or gmane, (or not-so nicely on archives.postgresql.org) * After I submitted my comments where do I go? * Do I submit them to -patches? * Or hackers? * What about cross threads? Well, generally your comments go as a reply to the patch, which should (in theory) be already on -patches * Am I going to have to do that for every single patch I review? Well, you make it sound hard, but really, there is only 1 out-of-band action needed to happen to make this all work easily: Somebody (author, or team of people reading the mailling-lists) update the wiki/tracker when 1) New patch comes in 2) New version of patch is sent 3) A decision/consensus on a patch (or part of it) has been made And in looking at this further, if I look at the Column Level privelages patch on the wiki, the archive page goes to a -hackers email. http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php * Do I now respond to the hackers list? Well, that's part of the general problem of the archives.postgresql.org... Lastly, how is this sustainable? I don't see anything that is reducing Bruce's workload. (for example) The only think that will ever reduce Bruce's workload is him trusting that things aren't getting overlooked. The value to the work Bruce does is that he really doesn't let anything slip through the cracks. One way we can do that is by having a tracker/wiki which is an easy place for Bruce to see that: Hey, this is/was looked after. I don't have to worry about this thing, I can delete it (and the followups to it) from my huge list of even more things to look at without expending lots of time re-reading the whole thread to make sure it didn't just die out -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] libpq type system 0.9a
Andrew Chernow wrote:
/* Only for results returned by PQresultDup. This
* will append a new tuple to res. A PGresAttValue
* is allocated and put at index 'res-ntups'. This
* is similar to pqAddTuple except that the tuples
* table has been pre-allocated. In our case, ntups
* and numAttributes are known when calling resultDup.
*/
int PQresultAddTuple(
PGresult *res,
char *value,
int len);
PQresultAddTuple is not quite correct. The below is its replacement:
int PQresultSetFieldValue(
PGresult *res,
int tup_num,
int field_num,
char *value,
int len)
Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue.
We feel this approach, which we initially thought wouldn't work, is
better than making pg_result public.
These functions could be useful outside of pqtypes, providing a way of
filtering/modifying a result object ... consider:
PGresult *execit(conn, stmt)
{
res = PQexec(conn, stmt);
if(some_app_cond_is_true)
{
newres = PQresultDup();
// ... customize tups and fields
//PQresultSetFieldDesc and PQresultSetFieldValue
PQclear(res);
res = newres;
}
return res;
}
// res could be custom built
res = execit(conn, stmt);
PQclear(res);
This is not an everyday need, but I'm sure it could provide some niche
app functionality currently unavailable. Possibly useful to libpq
wrapper APIs. Either way, it works great for pqtypes and avoids
exposing pg_result.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.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] Commit fest queue
Brendan Jurd wrote: Another is that the email list provides a push mechanism for putting the proposed patch under the noses of a bunch of people, a few of whom will hopefully take a sniff ;-). A tracker is very much more of a pull scenario where someone has to actively go looking for pending/proposed changes. The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. This is trivial to configure in a real tracker. Less so for a wiki page, but it could still be accomplished with the careful application of script-fu. Not sure how others feel, but automated emails of come see my new stuff are kind of annoying if you get alot of them because you can't actually act on the email itself --- you have to take the step of going to the web site, which may be OK if they are clickable links, but you do end up hopping in and out of email. And if you read something on the web site then get an email it is hard to know if you have seen that entry already. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake [EMAIL PROTECTED] writes: But now what? If you've got substantive comments to make, you make them by replying to the original email, same as it ever was. The wiki page is an index of email threads that need attention. Small comments can just be left on the wiki page, but that's not the way to have significant discussions. 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] Commit fest queue
Stefan Kaltenbrunner wrote: Gregory Stark wrote: Brendan Jurd [EMAIL PROTECTED] writes: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. Unfortunately that is the typical way to solve this. And it's awful. It's like the ubiquitous cryptic phone call in movies saying can't talk right now but there's something you should know. Meet me under the bridge And the guy dies before you meet him --- that is too funny. :-) -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Index AM change proposals, redux
* GIT (Grouped Index Tuple) indexes, which achieve index space savings in btrees by having a single index tuple represent multiple heap tuples (on a single heap page) containing a range of key values. I am not sure what the development status is --- Heikki had submitted a completed patch but there seemed to be agreement on making changes, and that's not been done AFAIK. The really serious problem I've got with it is that it'd foreclose the possibility of returning actual index keys from btree indexes, thus basically killing the usefulness of that idea. I'm not convinced it would offer enough gain to be worth paying that price. Another issue is that we'd need to check how much of the use-case for GIT has been taken over by HOT. I do not see the serious problem ? The one key that is stored would represent all tuples it points to. So the interface could eighter be designed to allow skipping the key in one go, or return the same key repeatedly. All that the second approach would need is return the key and the heap tuple pointer in two different vars. Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Peter Eisentraut [EMAIL PROTECTED] writes: Am Donnerstag, 10. April 2008 schrieb Tom Dunstan: Even so I reckon that would create vastly more noise than signal in the eventual tracker - part of the existing problem has been that wading through list archives is a pain for someone wanting to know the current status of a patch. I can't see the above helping that. We don't actually receive that many new patches or bugs. One or two people going through the tracker once a week and closing the closed issues would be quite doable. Yes, if we're just tracking patches or major proposals in a bug tracker. The hard part is actually deciding that they're closed. It's a big very cat-like herd of community members here. Reaching a consensus on taking action takes a long time and much teeth gnashing. Note that some people here are pushing a tracker as a way to organize the mailing lists and keep all discussions about the proposed changes from design to committing. I think they're crazy but they keep proposing that their favourite magical tracker will do it automatically. I think it will just end up looking like Bruce's lists where we couldn't even figure out how many patches were buried in those 2,000 messages. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GiST opclass and varlena
Dimitri Fontaine [EMAIL PROTECTED] writes: It turned around the error was related to the definition of my gpr_penalty() function, which I wanted to expose as the GiST internal and a SQL callable one too (for debugging and tests purpose). I forgot to define the internal one in the prefix.c side of things, got no complaint whatsover (nor at compile time neither at prefix.sql installation time) but garbage as data in __pr_penalty() function (not respecting GiST calling conventions). I'm getting interested now. How was __pr_penalty defined? What was the declaration you were missing in prefix.c? Was it specifically related to a varlena or was it a char or something like that? And was it something gcc -Wall was warning about or somehow was it slipping by? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS 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: [DOCS] [HACKERS] [SQL] pl/PgSQL, variable names in NEW
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: From what I can see on CPAN (unless I am missing something) DBD::PgSPI hasn't been updated since 2004 and is at version 0.2. Oh, if it's not a live project then that changes things entirely. +1 for just dropping the mention. Done. -- Alvaro Herrerahttp://www.CommandPrompt.com/ 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] Commit fest queue
Joshua D. Drake [EMAIL PROTECTED] writes: Am I supposed to look at the wiki page or bruce pages, or am I supposed to replying on the list about something. All of which happen during this fest. We were maintaining status on both pages for this fest, as an experiment to see which was more usable. IMHO the experiment is over and the wiki page won. 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] Commit fest queue
On Thu, 10 Apr 2008 11:15:08 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: * Where do I comment? In your mail program. To where? Development discussion is supposed to happen on -hackers but a patch is likely on -patches. Although we are allowed to discuss on -patches as long as it is limited, but then we push the discussion back to -hackers. How do you propose to track that? * How do I track it in the future? * Do I go to the wiki page again? Well, only if you want to pull the last status (i.e. someone else, not you may have updated it, and you haven't set yourself to be notified on changes). But again, since it's by email, you already have it all in your inbox, right? Do I? What if I am only using USENET to interfact? What if I just purged my mailbox because I get over 4500 messages a month from these lists? * If I go to the wiki page again and click on the patch is it going to take me right back to the archive page? Only if the wiki/tracker *hasn't* been updated. How do I know? Uh, don't you read your e-mail already? Any comment/discussions on the patch would have had you in the reply-to chain. All nicely threaded in your mail reader or gmane, (or not-so nicely on archives.postgresql.org) No it won't :). You are new here aren't you :P. It will be spread amongst at a minimum of two lists. * After I submitted my comments where do I go? * Do I submit them to -patches? * Or hackers? * What about cross threads? Well, generally your comments go as a reply to the patch, which should (in theory) be already on -patches Unless it gets into deeper discussion, then we are supposed to push it to -hackers and why do I have two interfaces again? One interface should be the goal. * Am I going to have to do that for every single patch I review? Well, you make it sound hard, but really, there is only 1 out-of-band action needed to happen to make this all work easily: Aidan it isn't hard, it ridiculous and inefficient. We are continually reinventing the wheel because we think we will somehow make it more round when in actuality all the other mature FOSS projects out there figured this out long ago. * Do I now respond to the hackers list? Well, that's part of the general problem of the archives.postgresql.org... What? I would never expect to track between mailing lists. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 11:17:37 -0400 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: But now what? If you've got substantive comments to make, you make them by replying to the original email, same as it ever was. The wiki page is an index of email threads that need attention. Tom I think you missed my point. I am long past email client here. I have opened a web browser, gone to a wiki, which pointed me to a archives page, which has a patch, which I have downloaded, reviewed and I am now ready to reply Oh but wait: I now need to open my mail client (fair enough, with me it is alt-tab), go to my projects-postgresql folder, put a search string in the search field, find the correct email, reply to the email with my comments, and possibly an updated patch or a patch to the patch. Or :) I can open a web browser, go to tracker.postgresql.org, review the list of open patches, click one, download, review, comment, upload new patch if required, done. Which would you honestly rather do? Especially if there was a email interface as well? Sincerely, Joshau D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GiST opclass and varlena
Le jeudi 10 avril 2008, Gregory Stark a écrit :
I'm getting interested now. How was __pr_penalty defined? What was the
declaration you were missing in prefix.c?
In fact __pr_penalty is the internal code called from both the SQL callable
functions (and some other calling sites). The problem was that I missed some
SQL callable definitions and it got called with internal parameters instead
of the prefix_range * it expects.
Details:
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/prefix/prefix/prefix.c.diff?r1=1.33r2=1.32
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/prefix/prefix/prefix.sql.in.diff?r1=1.15r2=1.14
Was it specifically related to a varlena or was it a char or something like
that?
The datatype I'm playing with is prefix_range and is used as a varlena:
typedef struct {
char first;
char last;
char prefix[1]; /* this is a varlena structure, data follows */
} prefix_range;
Then have a look at make_varlena() function and those macros:
#define DatumGetPrefixRange(X)((prefix_range *)
PREFIX_VARDATA(DatumGetPointer(X)) )
#define PrefixRangeGetDatum(X)PointerGetDatum(make_varlena(X))
#define PG_GETARG_PREFIX_RANGE_P(n)
DatumGetPrefixRange(PG_DETOAST_DATUM(PG_GETARG_DATUM(n)))
#define PG_RETURN_PREFIX_RANGE_P(x) return PrefixRangeGetDatum(x)
And was it something gcc -Wall was warning about or somehow was it slipping
by?
I didn't see any errors from gcc nor from PostgreSQL. I just was using the
following function definition for the two following SQL functions:
PG_FUNCTION_INFO_V1(pr_penalty);
Datum
pr_penalty(PG_FUNCTION_ARGS)
{
float penalty = __pr_penalty(PG_GETARG_PREFIX_RANGE_P(0),
PG_GETARG_PREFIX_RANGE_P(1));
PG_RETURN_FLOAT4(penalty);
}
CREATE OR REPLACE FUNCTION gpr_penalty(internal, internal, internal)
RETURNS internal
AS 'MODULE_PATHNAME'
LANGUAGE 'C' STRICT;
CREATE OR REPLACE FUNCTION gpr_penalty(prefix_range, prefix_range)
RETURNS float4
AS 'MODULE_PATHNAME'
LANGUAGE 'C' STRICT;
This last one is now pr_penalty and as a matching function defined in the
prefix.c file, which was not the case when all was wrong. And of course the
gpr_penalty code has been rewrote to be correct WRT its arguments processing.
Sorry to be using CVS at pgfoundry, if it was something more elaborate a
revision id could get you easily to the buggy version, here you'll have to
play some cvs game to get the version before the commit with this message, if
you wanted to try the bug yourself:
Respect GiST calling conventions for gpr_penalty()
Hope this helps, regards,
--
dim
signature.asc
Description: This is a digitally signed message part.
Re: [HACKERS] Commit fest queue
Joshua D. Drake wrote: And in looking at this further, if I look at the Column Level privelages patch on the wiki, the archive page goes to a -hackers email. http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php * Do I now respond to the hackers list? Note that we expect that http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php and http://archives.postgresql.org/message-id/[EMAIL PROTECTED] are the same thing: a message on pgsql-hackers containing a patch and links to the subsequent discussion. You should be smart enough to figure out how to followup to that message. Hmm, I see two problems here -- one is that it's not obvious what list the message is in. I'll try to add the list name as part of the title. (I wonder what should happen if a message is posted to more than one list.) The other one is that the message-id page is not getting updated w.r.t. the thread index/main index links ... (If you try thread index on the message-id link, it doesn't work, but it does work on the other one.) Will fix. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue]
Aidan Van Dyk wrote: Lastly, how is this sustainable? I don't see anything that is reducing Bruce's workload. (for example) The only think that will ever reduce Bruce's workload is him trusting that things aren't getting overlooked. The value to the work Bruce does is that he really doesn't let anything slip through the cracks. One way we can do that is by having a tracker/wiki which is an easy place for Bruce to see that: Hey, this is/was looked after. I don't have to worry about this thing, I can delete it (and the followups to it) from my huge list of even more things to look at without expending lots of time re-reading the whole thread to make sure it didn't just die out Yes, the sooner someone applies or rejects a patch or idea the quicker I can remove it from my watch list and the fewer items I have to watch. Also, let me add the wiki does not have items that need discussion/feedback for this commit-fest. Is that going to be added someday? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Index AM change proposals, redux
Zeugswetter Andreas OSB SD [EMAIL PROTECTED] writes: ... The really serious problem I've got with it is that it'd foreclose the possibility of returning actual index keys from btree indexes, thus basically killing the usefulness of that idea. I'm not convinced it would offer enough gain to be worth paying that price. I do not see the serious problem ? The one key that is stored would represent all tuples it points to. No, the entry represents a range of values for which the one key is the lower bound. You don't know just what the keys are for the other tuples, unless you go to the heap and look. We could restrict GIT to only represent tuples with exactly the same key, but that takes away a whole lot of its use-case (especially so now that HOT is in there). 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] Commit fest queue]
Bruce Momjian wrote: Also, let me add the wiki does not have items that need discussion/feedback for this commit-fest. Is that going to be added someday? Sure, we can create a new section titled items needing discussion. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
* Joshua D. Drake [EMAIL PROTECTED] [080410 11:35]: I now need to open my mail client (fair enough, with me it is alt-tab), go to my projects-postgresql folder, put a search string in the search field, find the correct email, reply to the email with my comments, and possibly an updated patch or a patch to the patch. Or :) I can open a web browser, go to tracker.postgresql.org, review the list of open patches, click one, download, review, comment, upload new patch if required, done. Which would you honestly rather do? Especially if there was a email interface as well? Anything can be framed favourably, or not: But wait, I now need to open my web browser (fair enough, with me it is alt-tab), google for the postgresql tracker and find the correct site, look at some list of patches, click one, download, choose where to save it, and review it, then try and find my way back to the proper page, try to type a sane review into some textbox with limited editing capabilities, possibly find the upload new patch button, click it, check some box to say if it's a new patch, or a patch to the patch, try and find the patch on my system, add it, and upload it. Or ;-) I can grab the messageid (or mhonorc url, I've got tools to get the message id out if it), directly open the message in my reader of choice, and have the patch, all the discussion threaded nicely, so I can get a quick overview of some of the other things that might be happening with it), and simply reply to it with my review. Which would you honestly rather do? -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 11:41:51 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: Joshua D. Drake wrote: And in looking at this further, if I look at the Column Level privelages patch on the wiki, the archive page goes to a -hackers email. http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php * Do I now respond to the hackers list? Note that we expect that http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php and http://archives.postgresql.org/message-id/[EMAIL PROTECTED] are the same thing: a message on pgsql-hackers containing a patch and links to the subsequent discussion. You should be smart enough to figure out how to followup to that message. Maybe but that isn't the point I am trying to make :). I shouldn't have to be. The most successful interfaces are those that are so dumb that my mother can use them. It should *always* be obvious exactly what I need to do. I should never have to guess (in terms of the interface it self). Consider graphical email clients. I want to send a message: Compose or New I want to reply to a message: Reply I want to read a message: Click Consider IM: I want to talk to mom: click, type Mom wants to get my attention: screen popup or glowing icon This is why email is so darn powerful. It isn't ubiquitous because of its age, its ubiquitous because it is dumb simple to use. Email can be just as complicated if I chose. Just add PGP to the mix, auto filters, aliases, tags, labels (not sure the difference but I have both), multiple identities etc.. But those are all features and are not required for email itself to work. The base requirements for this process must be so simple, so easy, that even if the person has never seen a C patch in his/her life they understand what is trying to be achieved. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue]
Bruce Momjian wrote: Also, let me add the wiki does not have items that need discussion/feedback for this commit-fest. Is that going to be added someday? I take that back. The March wiki has two items that are clearly not ready to be applied but need discussion that is happening: http://wiki.postgresql.org/wiki/CommitFest:March But the wiki is missing other items that need discussion: http://momjian.us/cgi-bin/pgpatches like the index items. So if the wiki is only supposed to only have patches worthy of review for possible application, the wiki should be empty at this point. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 11:53:09 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: I can grab the messageid (or mhonorc url, I've got tools to get the message id out if it), directly open the message in my reader of choice, and have the patch, all the discussion threaded nicely, so I My mail reader will do nothing with the message id. Likely the most widely used mail readers out there won't either. (I would have to check but I doubt Thunderbird for example would have any options, nor would outlook) Not everyone is willing to use mutt. Thanks, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake wrote: On Thu, 10 Apr 2008 11:17:37 -0400 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: But now what? If you've got substantive comments to make, you make them by replying to the original email, same as it ever was. The wiki page is an index of email threads that need attention. Tom I think you missed my point. I am long past email client here. I have opened a web browser, gone to a wiki, which pointed me to a archives page, which has a patch, which I have downloaded, reviewed and I am now ready to reply Oh but wait: I now need to open my mail client (fair enough, with me it is alt-tab), go to my projects-postgresql folder, put a search string in the search field, find the correct email, reply to the email with my comments, and possibly an updated patch or a patch to the patch. Uh, how do you reply to an email from the archives web page? The only way I have found to do it is to cut/paste the email addresses (and fix the obfuscation), or download the mbox file. Because my personal system uses email I can reply to the email, or someone can download the mbox that goes with my queue. Either way going from the web to email is an extra step, for sure. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake [EMAIL PROTECTED] writes: Or :) I can open a web browser, go to tracker.postgresql.org, review the list of open patches, click one, download, review, comment, upload new patch if required, done. And then no one sees your revised patch (except someone watching the tracker like a hawk). This is not the way to have a discussion, which is fundamentally what our process is. As I said before, I am uninterested in any proposals for a fundamental change in our processes. I want an index page that makes sure that nothing that's supposed to get done in a commit fest gets forgotten. I do not need what you propose, and I wouldn't voluntarily use it. 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] Commit fest queue
Joshua D. Drake [EMAIL PROTECTED] writes: The message comes up. Granted... very, very cool that this is all linked, so +1. But now what? Now you return, suitably enlightened, to your regularly scheduled life talking about code (or trackers) on pgsql-hackers and other mailing lists. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Alvaro Herrera [EMAIL PROTECTED] writes: (I wonder what should happen if a message is posted to more than one list.) That's a good question. I suppose there are actually multiple archive entries in that case --- which one is the message-id link taking me to? I guess whichever list appears first in the To/Cc fields would be the best choice. This is a bit of a problem though, since if discussion ensued on the other list(s) you'd not see any link to it on that page. One of the things that would have to happen with any tracker system is that we'd need links to each of the related threads when a discussion gets fragmented like that. Is that a candidate for automation, or will it have to be done manually? (Another thing that really, really, really needs to get fixed is the archives' inability to link threads across month boundaries.) 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] Commit fest queue
Joshua D. Drake wrote: The base requirements for this process must be so simple, so easy, that even if the person has never seen a C patch in his/her life they understand what is trying to be achieved. I'm pretty sure we don't want a person who has never seen a C patch in his life anywhere near our patch queue. -- Alvaro Herrerahttp://www.CommandPrompt.com/ 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] Commit fest queue
On Thu, 10 Apr 2008 12:07:43 -0400 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Or :) I can open a web browser, go to tracker.postgresql.org, review the list of open patches, click one, download, review, comment, upload new patch if required, done. And then no one sees your revised patch (except someone watching the This is false. As I said before, I am uninterested in any proposals for a fundamental Yes Tom I am aware of your particular opinion which is why I mention and email interface as well. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] libpq type system 0.9a
Andrew Chernow [EMAIL PROTECTED] writes: Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue. We feel this approach, which we initially thought wouldn't work, is better than making pg_result public. That doesn't seem to me to fit very well with libpq's internals --- in particular the PQresult struct is not designed to support dynamically adding columns, which retail PQresultSetFieldDesc() calls would seem to require, and it's definitely not designed to allow that to happen after you've begun to store data, which the apparent freedom to intermix PQresultSetFieldDesc and PQresultSetFieldValue calls would seem to imply. Instead of PQresultSetFieldDesc, I think it might be better to provide a call that creates an empty (of data) PGresult with a specified tuple descriptor in one go. 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] Commit fest queue
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: (I wonder what should happen if a message is posted to more than one list.) That's a good question. I suppose there are actually multiple archive entries in that case --- which one is the message-id link taking me to? The one on the list which was first processed :-( They are processed in alphabetical order, so pgsql-hackers wins over pgsql-patches. However, there is an additional consideration: sometimes, Mhonarc rewrite message pages (for example because it needs to fix the hyperlinks which go to the thread index, when the thread index grows and the current message goes to a later page). If the link in pgsql-patches moves but the one in pgsql-hackers does not, then the pass over pgsql-patches would take precedence. (I don't really know if this actually happens or not -- it's pure speculation). I guess whichever list appears first in the To/Cc fields would be the best choice. This is a bit of a problem though, since if discussion ensued on the other list(s) you'd not see any link to it on that page. I don't see any way to solve this problem with the current implementation. I'm thinking we should ditch it and implement the one using the database. One of the things that would have to happen with any tracker system is that we'd need links to each of the related threads when a discussion gets fragmented like that. Is that a candidate for automation, or will it have to be done manually? Perhaps it could be done with the message-id on the search database. (Another thing that really, really, really needs to get fixed is the archives' inability to link threads across month boundaries.) Agreed. I examined Mhonarc to see if I could do it, but I don't think it's anywhere near its possibilities. I'm afraid we would have to switch to something completely different. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
* Joshua D. Drake [EMAIL PROTECTED] [080410 11:55]: On Thu, 10 Apr 2008 11:53:09 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: I can grab the messageid (or mhonorc url, I've got tools to get the message id out if it), directly open the message in my reader of choice, and have the patch, all the discussion threaded nicely, so I My mail reader will do nothing with the message id. Likely the most widely used mail readers out there won't either. (I would have to check but I doubt Thunderbird for example would have any options, nor would outlook) Not everyone is willing to use mutt. s/mutt/a decent MUA/ ;-) But if you don't want to use a local MUA with those capabilities, then just go: http://news.gmane.org/[EMAIL PROTECTED] or http://www.highrise.ca/cgi-bin/mhonarc/http://archives.postgresql.org/pgsql-hackers/2008-04/msg00726.php And just click the action, and choose Followup And hey! It's all in your web-browser even, with a nice threaded interface of the discussion to boot! Now, if we could only get archives.postgresql.org to be as nice as that, or just punt to gmane for now ;-) Just for fun, put the following alias in your hosts file: 205.150.199.213 yugib.highrise.ca archives.postgresql.org And try that commitfest wiki page... a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Commit fest queue
* Joshua D. Drake [EMAIL PROTECTED] [080410 10:24]: Someone, anyone should be able to look exactly one place for the information required to process a patch. That one place is (and I think always should be, but I'm biased) going to be the mailling list. Of course we still have cvs etc.. but nobody on this list or new to the community should ever say to themselves, Which page am I supposed to go to? What list am I supposed to reply to now that I have feedback? Oh, I am supposed to go over to this wiki? Then what? Well, ideally, they would just reply to the message that introduced the patch. Then it would go to both the list and the author, where further discussion can happen. Mailing lists are really good at discussion, threads, etc. You should be able to say, Hey here is the history of the patch for materialized views and then 30 hours later say, Phew large patch but here is my feedback Right, so you look at the message with the patch, save the patch (or download it if it's just linked), work, review, etc, and then just reply to the message. Again, the maililng list is an excellent interface to discuss things, manage threads of discussion, etc. Basically, as Tom keeps saying the wiki is just an index into the mailing list archives. Any tracker may be able to do that, with more or less complexity. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Commit fest queue
* Joshua D. Drake [EMAIL PROTECTED] [080410 11:30]: On Thu, 10 Apr 2008 11:15:08 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: * Where do I comment? In your mail program. To where? Development discussion is supposed to happen on -hackers but a patch is likely on -patches. Although we are allowed to discuss on -patches as long as it is limited, but then we push the discussion back to -hackers. How do you propose to track that? Do I? What if I am only using USENET to interfact? What if I just purged my mailbox because I get over 4500 messages a month from these lists? No it won't :). You are new here aren't you :P. It will be spread amongst at a minimum of two lists. Unless it gets into deeper discussion, then we are supposed to push it to -hackers and why do I have two interfaces again? One interface should be the goal. What? I would never expect to track between mailing lists. All of these come down to the mailling-list. Last week I already asked about the distinction between -hackers and -patches, and what I saw as the consensus is that there both pretty much the same thing, by different names, and lots most people file them both away together. And in my MUA setup, (and gmane, a public NNTP interface to mailling-lists), threads *are* followed across lists seemlessly. I like this ability, so to me the -patches and -hackers distinction is just and address I pretty much ignore... But again, the point is, PostgreSQL development (and sure, I'm new, but I've been reading these lists for quite a while) has traditionally been via e-mail and the mailling-lists. Sure, there are some warts (like the current archives), but it's worked. *I* think trying to change the pending patches management *and* the whole development method of PostgreSQL at the same time isn't going to fly. And at least Tom seems against it too. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] libpq type system 0.9a
Andrew Chernow [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Surely you would just provide a function to get pqtypes errors separate from
libpq errors?
That's extremely akward. Consider the below.
I'm just as suspicious of this as Greg is. In particular, I really
disagree with PQgetf storing an error message into a PGresult, because
that creates a semantic inconsistency. Up to now, PGresults have come
in two flavors, okay (which might hold data) and error (which hold
error messages). Now you're proposing to stick an error message into
an okay data-holding PGresult. Does that turn it into an error
result? Does its PQresultStatus change? Does it maybe forget the data
it used to hold?
An even more fundamental objection is that surely PQgetf's PGresult
argument should be const.
int getvalues(PGresult *res, int *x, char **t)
{
return PQgetf(res, get the int and text);
}
if(getvalues(res, x, t))
printf(%s\n, PQresultErrorMessage(res));
This example is entirely unconvincing. There is no reason to be checking
PQresultErrorMessage at this point --- if you haven't already checked the
PGresult to be okay, you should certainly not be trying to extract
fields from it. So I don't see that you are saving any steps here.
PQgetf should behave exactely as PQgetvalue does, in regards to errors.
Uh-huh. You'll notice that PQgetvalue treats the PGresult as const.
Same holds true for PGconn.
I'm not convinced about that side either. It doesn't fail the basic
const-ness test, perhaps, but it still looks mostly like you are trying
to avoid the necessity to think hard about how you're going to report
errors. You're going to have to confront the issue for operations that
only take a PGresult, and once you've got a good solution on that side
it might be better to use it for PQputf too.
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] Concurrent psql API
Gregory Stark [EMAIL PROTECTED] writes: Csaba Nagy [EMAIL PROTECTED] writes: For interactive use in the above mentioned scenario you can use the 'screen' command and start as many psqls as needed Sure, or you could just start multiple xterms or emacs shell buffers (my preferred setup). Yeah, that's an awfully good point, and I have to admit I'd generally prefer multiple xterms too. But I'm sure there are people who would prefer C-z too. AFAICT, supporting C-z will add a pretty significant increment of definitional complexity, implementation complexity, and portability risks to what otherwise could be a relatively small patch. I don't want to buy into that just because some people might use it. I note also that if we start trapping C-z, it would stop working for what it works for now, namely suspending psql so you can do something else in that window. So, +1 for thinking about this entirely as a scripting feature. 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] [PATCHES] libpq type system 0.9a
Tom Lane wrote: Andrew Chernow [EMAIL PROTECTED] writes: Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue. We feel this approach, which we initially thought wouldn't work, is better than making pg_result public. That doesn't seem to me to fit very well with libpq's internals --- in particular the PQresult struct is not designed to support dynamically adding columns, which retail PQresultSetFieldDesc() calls would seem to require, and it's definitely not designed to allow that to happen after you've begun to store data, which the apparent freedom to intermix PQresultSetFieldDesc and PQresultSetFieldValue calls would seem to imply. Instead of PQresultSetFieldDesc, I think it might be better to provide a call that creates an empty (of data) PGresult with a specified tuple descriptor in one go. regards, tom lane Are you against exposing PGresAttDesc? PGresult *PQresultDup( PGconn *conn, PGresult *res, int ntups, int numAttributes, PGresAttDesc *attDescs); If you don't want to expose PGresAttDesc, then the only other solution would be to pass parallel arrays of attname[], tableid[], columnid[], etc... Not the most friendly solution, but it would do the trick. Recap: Use new PQresultDup, throw out setfielddesc and keep setfieldvalue the same. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.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] SQL fast in PSQL, very slow using MS.NET driver
On Thu, Apr 10, 2008 at 5:27 AM, Ashish Sharma [EMAIL PROTECTED] wrote: Thanks for the response. Below are the details: What queries are you running? We are running normal SQLs and DMLs. Even simple queries like select * from... are showing the described behavior. What version of Npgsql? NPGSQL ver. 1.97.1.0 No performance problem with it. But it may be good to update to our latest beta3 release. Are you using prepared statements? We have performance issues with prepared statements. If it is so, can you try without prepared statements? We are not you prepared statements. Ok. You can discuss this also in our forums: forums.npgsql.org The dotNet version we are using is 2.0, PostgreSQL 8.2.4 (on RHEL4) Appreciate the support. You are welcome. Please, when using forums, give us what queries you are running so we can make some tests to see what can be happening. Thanks in advance, Ashish. -- Regards, Francisco Figueiredo Jr. http://fxjr.blogspot.com http://www.npgsql.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Index AM change proposals, redux
Teodor Sigaev [EMAIL PROTECTED] writes: * Proposed change to let both amgetnext and amgetmulti mark returned tuples as candidate matches, that is in need of rechecking of quals ... indexes). There seemed to be some possible marginal use for it in GIST indexes, but I'm not convinced that's a sufficient reason to complicate the APIs. This is good way to eliminate awful operation '@@@' without performance loss. Oh yeah, that kluge :-(. Okay, that's probably a sufficient reason all by itself. * Proposed changes to allow amgetnext to return the actual index keys, allowing certain types of unindexable quals to be checked without having to fetch the heap entry. For example a LIKE condition could be fully checked against the index entry. Since certain types of indexes (GIN now, possibly hash in future) are incapable of doing this, there'd GiST too, because type of storage may be differ from type to be indexed. The same touches GIN too. Is this the case for *all* GiST and GIN indexes, or might we need a per-index (rather than per-AM) flag to tell whether the original keys are available? 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] Index AM change proposals, redux
Heikki Linnakangas [EMAIL PROTECTED] writes: Tom Lane wrote: A bigger issue is whether this is worth applying when nobody seems to be working on either of the main uses for it (bitmap indexes and GIT indexes). There seemed to be some possible marginal use for it in GIST indexes, but I'm not convinced that's a sufficient reason to complicate the APIs. It has some merit on its own. Yeah, and Teodor's point about cleaning up the @@@ hack pretty much seals the deal for me. Unless anyone has objections, I will review and apply Heikki's patch http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php which covers both the amgetmulti return-a-bitmap change and the candidate-matches change. (Heiiki, you don't have a later version of that do you?) The remaining topics associated with index AMs are closed for this commit fest, unless anyone has specific questions they want discussed right now... 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
