Re: [HACKERS] Posting to hackers and patches lists
Gregory Stark napsal(a): Josh Berkus [EMAIL PROTECTED] writes: How about hacking together a simple patch tracker instead, as Bruce suggested? I've never found e-mail to be a particularly good way to track patches. The thing is that we don't just want to track patches. We want to talk about patches. I think we want to have both. If you have big patch you don't want go through all patch again and again when new version is released with only few changes. If you are able to have diff between two patch versions you are able preform easy check if all comments are already fixed. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ecpg crash
On Sat, May 10, 2008 at 12:14:57AM -0300, Euler Taveira de Oliveira wrote: While i'm working on a ecpg patch I found a bug in ecpg code. The simple program above could reproduce it. But basically it crashes (segfault) because it's trying to use a inexistent connection when we're preparing a statement. Don't know if it deserves a ecpg_log() message. A possible fix is attached. Let me dig into this some more before committing this fix. I wonder if the same problem holds for other use cases. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Posting to hackers and patches lists
Zdenek Kotala [EMAIL PROTECTED] writes: Gregory Stark napsal(a): Josh Berkus [EMAIL PROTECTED] writes: How about hacking together a simple patch tracker instead, as Bruce suggested? I've never found e-mail to be a particularly good way to track patches. The thing is that we don't just want to track patches. We want to talk about patches. I think we want to have both. If you have big patch you don't want go through all patch again and again when new version is released with only few changes. If you are able to have diff between two patch versions you are able preform easy check if all comments are already fixed. Ah, that's not something a patch tracker or a mailing list would solve. There is a tool that would solve this -- a revision control system. We aren't using CVS the way it's really intended. If all this development happened on branches then people could go look at the current version at any point, not just when authors decide to announce it. And people could generate diffs between the last time they looked at that branch and now etc. Now the problem is that CVS sucks and creating branches is a heavyweight operation which imposes a burden forever more. Also there is no access control system so you cannot grant commit access to just one branch. There are newer revision control systems where anyone can create a branch at any time and keep it on their local machine. They fit our development model much better than CVS when you include the development happening outside the committers and the main tree. -- 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] constraint exclusion analysis caching
Stephen Frost [EMAIL PROTECTED] writes: I'd rather get responses to my emails through the list than directly to me. Additionally, I don't really need to get two copies of every email sent to me on a mailing list. Then doesn't setting it to: Andrew Dunstan [EMAIL PROTECTED],PostgreSQL-development pgsql-hackers@postgresql.org do precisely the opposite of what you would want? -- 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] Posting to hackers and patches lists
Gregory Stark napsal(a): Zdenek Kotala [EMAIL PROTECTED] writes: Gregory Stark napsal(a): Josh Berkus [EMAIL PROTECTED] writes: How about hacking together a simple patch tracker instead, as Bruce suggested? I've never found e-mail to be a particularly good way to track patches. The thing is that we don't just want to track patches. We want to talk about patches. I think we want to have both. If you have big patch you don't want go through all patch again and again when new version is released with only few changes. If you are able to have diff between two patch versions you are able preform easy check if all comments are already fixed. Ah, that's not something a patch tracker or a mailing list would solve. There is a tool that would solve this -- a revision control system. OK. I little bit confused what patch tracer should do. Is it only for tracking discuss about patches? We aren't using CVS the way it's really intended. If all this development happened on branches then people could go look at the current version at any point, not just when authors decide to announce it. And people could generate diffs between the last time they looked at that branch and now etc. Yeah, I discussed this with Peter E. during his Prague visit and it should be big deal for code reviewing and new feature development. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bloated heapam.h
Alvaro Herrera napsal(a): Others are more conflictive. For example syncscan.c is keeping the prototypes for its own functions on heapam.h. Also pruneheap.c and rewriteheap.c. As a result, not only themselves need to include heapam.h (without any other need for it), but they force some other files into including heapam.h to get their prototypes. I think this is a mistake; I propose splitting those prototypes to their own files, and #including those as appropriate. Objections? I have similar thing in my TODO list. See my patch from March commit fest and discussion. I need solve two main issues - remove postgres.h from binaries and keep history of structures (for pg_upgrade project). My idea is split structures and functions in separate header files. Zdenek http://archives.postgresql.org/pgsql-patches/2007-10/msg00197.php http://archives.postgresql.org/pgsql-patches/2008-04/msg00149.php -- Sent 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
Joshua D. Drake [EMAIL PROTECTED] writes: Tom Lane wrote: Why, and exactly what would you define as appropriate naming style? The user has always been free to pick whatever constraint name he wants. Well it should be optional but it would be nice if we had the option to have it renamed per the default... meaning the same output if I were to do this: If you want that, you can rename the index (either before or afterwards). I don't see any reason to clutter the make-constraint-from-index command with questions of renaming. 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] Setting a pre-existing index as a primary key
Tom Lane wrote: Well it should be optional but it would be nice if we had the option to have it renamed per the default... meaning the same output if I were to do this: If you want that, you can rename the index (either before or afterwards). I don't see any reason to clutter the make-constraint-from-index command with questions of renaming. As a counter point, I don't see any reason to make the DBA's life harder. Sure it is just one step but it is a human step, prone to error and taking more time than it should. Why not just make it easy? Especially when the easy isn't sacrificing data integrity or quality of product? Sincerely, Joshua D. Drake 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] Setting a pre-existing index as a primary key
Joshua D. Drake wrote: Tom Lane wrote: Well it should be optional but it would be nice if we had the option to have it renamed per the default... meaning the same output if I were to do this: If you want that, you can rename the index (either before or afterwards). I don't see any reason to clutter the make-constraint-from-index command with questions of renaming. As a counter point, I don't see any reason to make the DBA's life harder. Sure it is just one step but it is a human step, prone to error and taking more time than it should. Why not just make it easy? Especially when the easy isn't sacrificing data integrity or quality of product? Because that's not the basis on which we decide to add features. You need to asses the code complexity, the potential benefit and number of likely users. In this case, the amount of code required for what would be nothing more than syntactic sugar for what is in any case a very simple statement makes me agree with Tom. 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] Setting a pre-existing index as a primary key
Joshua D. Drake [EMAIL PROTECTED] writes: As a counter point, I don't see any reason to make the DBA's life harder. Sure it is just one step but it is a human step, prone to error and taking more time than it should. Why not just make it easy? I don't see that decorating infrequently-used statements with bizarre options that duplicate the functionality of other commands is making it easy. Apparently your definition of easy depends entirely on keystrokes and not at all on memory/cognitive burden. IMHO a utility command should do one easily-explained thing. The fewer options the better. 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] constraint exclusion analysis caching
Stephen Frost wrote: (BTW, why does your MUA set Mail-Followup-To: (and do it badly, what's more) ?) I'm amazed at the number of people who ask me this.. Guess it's just different for different communities. Basically, I like to keep my mail in the different folders it belongs in, so I'd rather get responses to my emails through the list than directly to me. Additionally, I don't really need to get two copies of every email sent to me on a mailing list. I am amazed that you don't see that what your MUA is doing is actually both wrong and that it inconveniences people. For example, because it put *my* address in the list for your message above, it caused my MUA quite correctly to add a To: line to myself, which I certainly didn't want to do. And it's completely unnecessary. For example, I have set my majordomo preferences for the postgresql.org lists not to send me copies of emails where I am also in the To: or Cc: lines. After doing that I get no duplicates. And I don't casue anyone else to have to edit the addresses when they reply to my mail. If you want to ensure that you reply to a list, use an MUA that has a reply-to-list command - I see you use mutt, which has such a command IIRC. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Setting a pre-existing index as a primary key
Tom Lane wrote: Apparently your definition of easy depends entirely on keystrokes and not at all on memory/cognitive burden. I was trying to remove one opportunity for human error, which is tied to memory and cognitive burden. It is very easy to fat finger something. Is it a critical error? No. Is it obnoxious to have to go back and fix it, yes. When you are going back to fix, are you going to be grousing about how PostgreSQL doesn't make this easier, maybe. IMHO a utility command should do one easily-explained thing. The fewer options the better. I would agree with this except that by my definition your argument fails. You are adding options by not allowing a sane default that applies consistency to the database. I believe this will cause more trouble than having the limitation in the first place. Anyway, I have made my arguments. I believe we are still in the middle of a commit fest. Sincerely, Joshua D. Drake -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Rethinking dependency traversal during DROP
I promise I won't expend any real effort on this until after the commitfest is over, but ... While working on the recently committed constraints patch, I got annoyed by the way in which DROP CASCADE frequently emitted noise messages. For instance: regression=# create table p1 (f1 int); CREATE TABLE regression=# create table c1 (f2 int check (f20)) inherits (p1); CREATE TABLE regression=# drop table p1 cascade; NOTICE: drop cascades to table c1 NOTICE: drop cascades to constraint c1_f2_check on table c1 DROP TABLE The check constraint is auto-dependent on c1, so really the second message shouldn't be there. The reason it is there is that the constraint also has a normal dependency on c1.f2, and if this pg_depend link is traversed first (which seems to almost always be the case) then you get the message. The findAutoDeletableObjects() scan that is supposed to prevent this behavior does not, because it only goes as far as the objects that are directly auto- or internal-dependent on the original target object (ie, p1). I thought about fixing this by doing a new findAutoDeletableObjects() scan whenever we recurse, adding-on new objects to not complain about. This sort of works; I attach a test patch that does that, and the regression test output changes it induces, which seem to be all to the good. But it's a pretty ugly idea for a number of reasons: 1. With this patch, every single call to recursiveDeletion is preceded by findAutoDeletableObjects, which at the very least cries out for refactoring. 2. The above observation puts the final nail in the coffin of the original design idea, which was to do one recursive traversal of pg_depend links during DROP. It's indisputable that we now must traverse the entire link tree twice (at least!), and the cost of doing that seems annoying, especially when we are sitting there building various lists of the objects in memory anyway. 3. We have got various open bug reports centered around the fact that a cascaded DROP takes locks too late: http://archives.postgresql.org/pgsql-hackers/2007-01/msg00937.php http://archives.postgresql.org/pgsql-bugs/2007-03/msg00143.php http://archives.postgresql.org/pgsql-bugs/2007-12/msg00188.php If we are going to be forced into a two-pass approach, we really ought to try to solve those issues at the same time. So the idea I am toying with goes like this: 1. First, recursively scan the pg_depend tree to find every object that would have to be deleted in order to drop the initial target object(s). Take out locks on objects that are of lockable types before scanning for their referencing objects, but don't do anything else yet. Build an ObjectAddresses list in memory of the objects-to-drop, and annotate each entry with flags showing how we got to it (ie, via normal, auto, or internal dependency links). 2. Scan the ObjectAddresses list and issue notices about any objects that are reachable only via normal dependencies. If there are any, and it's not a CASCADE drop, error out. (This means we will fail in such a case after expending quite a lot less work than we do now.) 3. Scan the ObjectAddresses list back-to-front and perform the deletions. The back-to-front scan ensures dependent objects are deleted before depended-on ones, which is critical in a number of cases. I am not entirely certain that a back-to-front traversal is sufficient: there may need to be some kind of sorting step, or maybe we should just continue to drive the deletion pass off scans of pg_depend, seeing that we'll have to do those anyway to delete the pg_depend entries. So this is just a back-of-the-napkin sketch of how it might work. Comments? regards, tom lane Index: src/backend/catalog/dependency.c === RCS file: /cvsroot/pgsql/src/backend/catalog/dependency.c,v retrieving revision 1.71 diff -c -r1.71 dependency.c *** src/backend/catalog/dependency.c27 Mar 2008 03:57:33 - 1.71 --- src/backend/catalog/dependency.c10 May 2008 16:36:34 - *** *** 701,706 --- 701,708 (errmsg(drop cascades to %s, getObjectDescription(owningObject; + findAutoDeletableObjects(owningObject, oktodelete, depRel, true); + if (!recursiveDeletion(owningObject, behavior, msglevel, object, oktodelete, depRel, alreadyDeleted)) ok = false; *** *** 866,871 --- 868,875 (errmsg(drop cascades to %s, getObjectDescription(otherObject; + findAutoDeletableObjects(otherObject, oktodelete, depRel, true); + if
Re: [HACKERS] Posting to hackers and patches lists
On Sat, May 10, 2008 at 10:55:57AM +0100, Gregory Stark wrote: Zdenek Kotala [EMAIL PROTECTED] writes: Gregory Stark napsal(a): Josh Berkus [EMAIL PROTECTED] writes: How about hacking together a simple patch tracker instead, as Bruce suggested? I've never found e-mail to be a particularly good way to track patches. The thing is that we don't just want to track patches. We want to talk about patches. I think we want to have both. If you have big patch you don't want go through all patch again and again when new version is released with only few changes. If you are able to have diff between two patch versions you are able preform easy check if all comments are already fixed. Ah, that's not something a patch tracker or a mailing list would solve. There is a tool that would solve this -- a revision control system. There's already an official git repository, and it plays nicely with the official CVS it sits on top of :) http://git.postgresql.org/ Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: 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] bloated heapam.h
Zdenek Kotala wrote: Alvaro Herrera napsal(a): Others are more conflictive. For example syncscan.c is keeping the prototypes for its own functions on heapam.h. Also pruneheap.c and rewriteheap.c. As a result, not only themselves need to include heapam.h (without any other need for it), but they force some other files into including heapam.h to get their prototypes. I think this is a mistake; I propose splitting those prototypes to their own files, and #including those as appropriate. Objections? I have similar thing in my TODO list. See my patch from March commit fest and discussion. I need solve two main issues - remove postgres.h from binaries and keep history of structures (for pg_upgrade project). Yeah, I remember that. Is there any progress on that front? BTW I noticed that I was a bit careless in the description. rewriteheap already has its own rewriteheap.h file; and there's no point at all in separating pruneheap.c declarations into another file. The one that makes a bit more sense is a new syncscan.h. And there are a lot of things in heapam.h that actually correspond to tuple manipulation (heap_form_tuple and so on), so perhaps a new header file would be appropriate, but there's already htup.h which contains tuple-related stuff. -- 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] bloated heapam.h
Alvaro Herrera [EMAIL PROTECTED] writes: The one that makes a bit more sense is a new syncscan.h. And there are a lot of things in heapam.h that actually correspond to tuple manipulation (heap_form_tuple and so on), so perhaps a new header file would be appropriate, but there's already htup.h which contains tuple-related stuff. After actually looking at the header a bit ... +1 for moving fastgetattr, heap_getattr, and the heaptuple.c functions to htup.h. I don't see any big gain from relocating the other stuff; it seems to largely all use about the same set of typedefs. It looks to me actually that a large part of your complaint is that heapam.h #includes more than it has to. Have you tried just cutting its #include list to the minimum needed to compile its function declarations? Likely this would force more #includes in .c files but I don't object to that. (I might be wrong, but I believe that Bruce's script for removing unnecessary #includes is not bright enough to make such tradeoffs, so it'd let bloated #include lists in headers survive.) 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] Setting a pre-existing index as a primary key
So, would anyone be averse to something like the following: ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame If the user doesn't specify CONSTRAINT constraint_name, it will default to current implicit behavior of col_pkey. -Jonah On Sat, May 10, 2008 at 1:08 PM, Joshua D. Drake [EMAIL PROTECTED] wrote: Tom Lane wrote: Apparently your definition of easy depends entirely on keystrokes and not at all on memory/cognitive burden. I was trying to remove one opportunity for human error, which is tied to memory and cognitive burden. It is very easy to fat finger something. Is it a critical error? No. Is it obnoxious to have to go back and fix it, yes. When you are going back to fix, are you going to be grousing about how PostgreSQL doesn't make this easier, maybe. IMHO a utility command should do one easily-explained thing. The fewer options the better. I would agree with this except that by my definition your argument fails. You are adding options by not allowing a sane default that applies consistency to the database. I believe this will cause more trouble than having the limitation in the first place. Anyway, I have made my arguments. I believe we are still in the middle of a commit fest. Sincerely, Joshua D. Drake -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837 | 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] ecpg localization
Peter Eisentraut wrote: I suggest you keep working on this, and we will reconsider a more complete patch at a later date. This is a second try. Fix some issues pointed by Peter. It's a little fatter 'cause I worked on almost all of the strings. I attempted to mimic the postgresql style but I think that those strings need more work on as I pointed out in the first e-mail. Again, It is necessary to overhaul the ecpg emit-some-message-functions. For example, some of them have tips in it, other ones is just-for-information message, and so on. I don't have in mind what is a good draft for those messages. Suggestions? -- Euler Taveira de Oliveira http://www.timbira.com/ l10necpg2.tgz Description: application/compressed-tar -- Sent 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
Jonah H. Harris [EMAIL PROTECTED] writes: So, would anyone be averse to something like the following: ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame If the user doesn't specify CONSTRAINT constraint_name, it will default to current implicit behavior of col_pkey. This is all so that the primary key shows up with a nice PRIMARY KEY instead of just the unique index? The PREBUILT seems unnecessary in that syntax. -- 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] Setting a pre-existing index as a primary key
Yes, I just think PREBUILT conveys the meaning of the command more appropriately. I could care less though. On Sat, May 10, 2008 at 5:35 PM, Gregory Stark [EMAIL PROTECTED] wrote: Jonah H. Harris [EMAIL PROTECTED] writes: So, would anyone be averse to something like the following: ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame If the user doesn't specify CONSTRAINT constraint_name, it will default to current implicit behavior of col_pkey. This is all so that the primary key shows up with a nice PRIMARY KEY instead of just the unique index? The PREBUILT seems unnecessary in that syntax. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837 | 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] Setting a pre-existing index as a primary key
Jonah H. Harris wrote: Yes, I just think PREBUILT conveys the meaning of the command more appropriately. I could care less though. (Please don't top-answer) I don't think we should add new keywords unnecessarily. cheers andrew On Sat, May 10, 2008 at 5:35 PM, Gregory Stark [EMAIL PROTECTED] wrote: Jonah H. Harris [EMAIL PROTECTED] writes: So, would anyone be averse to something like the following: ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame If the user doesn't specify CONSTRAINT constraint_name, it will default to current implicit behavior of col_pkey. This is all so that the primary key shows up with a nice PRIMARY KEY instead of just the unique index? The PREBUILT seems unnecessary in that syntax. -- 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] Setting a pre-existing index as a primary key
Jonah H. Harris [EMAIL PROTECTED] writes: ALTER TABLE blah ADD ... PRIMARY KEY (...) USING PREBUILT INDEX index_hame If the user doesn't specify CONSTRAINT constraint_name, it will default to current implicit behavior of col_pkey. IOW, the default behavior is to rename the index? Doesn't seem to me to satisfy the principle of least surprise. I agree with Andrew that creating new keywords just for noise purposes is not gonna happen. 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] Setting a pre-existing index as a primary key
On Sat, May 10, 2008 at 11:55:29AM -0400, Tom Lane wrote: IMHO a utility command should do one easily-explained thing. The fewer options the better. Sticking to that principle makes for a better-maintained system. I agree. If we want to point out, You might rename your index afterwards to make it look like other default primary keys, I have no objection. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.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] ecpg localization
Euler Taveira de Oliveira wrote: This is a second try. I forgot to say that this patch doesn't include nls support to ecpg files automagically. If you guys think that it's is a Good Thing to do, we need to hack the preproc.y to hardcode the locale stuff; if you decide that it isn't necessary, we need to document that the nls support can be achieved by using the locale stuff. Comments? There is a bogus fprintf message at ecpg_gettext(), please remove it. -- Euler Taveira de Oliveira http://www.timbira.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] bloated heapam.h
Tom Lane wrote: +1 for moving fastgetattr, heap_getattr, and the heaptuple.c functions to htup.h. I don't see any big gain from relocating the other stuff; it seems to largely all use about the same set of typedefs. Ultimately that was my conclusion too. I tried moving the heaptuple.c functions to htup.h, but hit the problem that pg_dump.c wants to include that file. It then fails to compile because it doesn't know Datum (defined in postgres.h, so unavailable to frontend programs). I worked around that by enclosing the prototypes in #ifndef FRONTEND, but that seems ugly. Apparently the reason for pg_dump.c to need htup.h is getAttrName which needs system columns' attribute numbers. Of course, the first thing that comes to mind is that we should fix pg_dump to not require that header in the first place. Perhaps we can get the names by querying the server, at the same time we get the user column names. (Apparently this is only used to dump unique indexes on system columns.) The easiest actual solution, however, seems to be to move those attribute numbers to a separate header, say access/sysattrs.h. -- 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] bloated heapam.h
Alvaro Herrera [EMAIL PROTECTED] writes: Apparently the reason for pg_dump.c to need htup.h is getAttrName which needs system columns' attribute numbers. Of course, the first thing that comes to mind is that we should fix pg_dump to not require that header in the first place. Perhaps we can get the names by querying the server, at the same time we get the user column names. (Apparently this is only used to dump unique indexes on system columns.) The easiest actual solution, however, seems to be to move those attribute numbers to a separate header, say access/sysattrs.h. Yeah, probably. There is certainly no reason for a frontend program to be dealing in Datum; but it isn't unreasonable for it to know the system column numbers, since it can see those in the catalogs. I'm sure we have work in front of us to get these things separated out a bit better. 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
[HACKERS] another ecpg crash
Hi,
I found another bug when using 'exec sql include filename'. If you use a
filename that doesn't exist, ecpg crashes while trying to close a null
pointer. The above test case shows it. A possible fix is attached.
#include stdio.h
/* foo.h doesn't exist */
exec sql include foo;
int main(void)
{
return 0;
}
(gdb) bt
#0 0xb7a746fd in fclose@@GLIBC_2.1 () from /lib/libc.so.6
#1 0x080496e1 in mmerror (error_code=2, type=ET_FATAL, error=0xb7eeb0cc
Address 0xb7eeb0cc out of bounds)
at /a/pgsql/dev/pgsql/src/interfaces/ecpg/preproc/preproc.y:93
#2 0x08069d07 in parse_include () at
/a/pgsql/dev/pgsql/src/interfaces/ecpg/preproc/pgc.l:1270
#3 0x08067fa7 in base_yylex () at
/a/pgsql/dev/pgsql/src/interfaces/ecpg/preproc/pgc.l:1080
#4 0x0806d4ce in filtered_base_yylex () at
/a/pgsql/dev/pgsql/src/interfaces/ecpg/preproc/parser.c:64
#5 0x0804a8a8 in base_yyparse () at y.tab.c:20322
#6 0x0806ca35 in main (argc=2, argv=0xbff0ea94) at
/a/pgsql/dev/pgsql/src/interfaces/ecpg/preproc/ecpg.c:462
(gdb) print yyin
$1 = (FILE *) 0x0
--
Euler Taveira de Oliveira
http://www.timbira.com/
*** ./src/interfaces/ecpg/preproc/preproc.y.orig 2008-05-11 01:28:52.0 -0300
--- ./src/interfaces/ecpg/preproc/preproc.y 2008-05-11 01:43:24.0 -0300
***
*** 90,96
ret_value = error_code;
break;
case ET_FATAL:
! fclose(yyin);
fclose(yyout);
if (unlink(output_filename) != 0 *output_filename != '-')
fprintf(stderr, _(could not remove output file \%s\\n), output_filename);
--- 90,98
ret_value = error_code;
break;
case ET_FATAL:
! /* there are some cases (i.e. file not found) that the input is not available */
! if (!yyin)
! fclose(yyin);
fclose(yyout);
if (unlink(output_filename) != 0 *output_filename != '-')
fprintf(stderr, _(could not remove output file \%s\\n), output_filename);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] another ecpg crash
Euler Taveira de Oliveira wrote: Hi, I found another bug when using 'exec sql include filename'. If you use a filename that doesn't exist, ecpg crashes while trying to close a null pointer. The above test case shows it. A possible fix is attached. Huh, isn't the test backwards? --- 90,98 ret_value = error_code; break; case ET_FATAL: ! /* there are some cases (i.e. file not found) that the input is not available */ ! if (!yyin) ! fclose(yyin); fclose(yyout); if (unlink(output_filename) != 0 *output_filename != '-') fprintf(stderr, _(could not remove output file \%s\\n), output_filename); -- 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] another ecpg crash
Alvaro Herrera wrote: Huh, isn't the test backwards? In which way? I use a simple one but whatever test that uses 'exec sql include foo' and foo.h doesn't exist, it will crash. -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
