Re: [HACKERS] Cast your vote ...
Registration is easy, and pretty much anonymous... worth to promote our beloved database. :) Happy New Year, Daniel Marc G. Fournier said: Just got this in my mailbox: 2002 LinuxQuestions.org Members Choice Awards: http://www.linuxquestions.org/questions/showthread.php?s=78a8c06fbc1dcecd525 97decd6c56ad8threadid=39870 And we are way behind MySQL (like, d'ah!): http://www.linuxquestions.org/questions/poll.php?s=78a8c06fbc1dcecd52597decd 6c56ad8action=showresultspollid=168 The problem, of course, is that you have to be a registered member to vote, so its not an 'open poll' ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump.options.diff
On Thu, 2 Jan 2003 01:44:21 -0500, Serguei Mokhov [EMAIL PROTECTED] wrote:
Either way, something has to be donw about this...
Just another way to do it:
#if defined(HAVE_GETOPT_LONG)
#define PARMPREFIX '='
#else
#define PARMPREFIX ' '
#endif
static void
explain_option(char *shortform, char *longform, char *parm, char *desc)
{
int pos = 0;
printf( -%s, shortform);
pos += 3 + strlen(shortform);
#if defined(HAVE_GETOPT_LONG)
printf(, --%s, longform);
pos += 4 + strlen(longform);
#endif
if (parm) {
printf(%c%s, PARMPREFIX, parm);
pos += 1 + strlen(parm);
}/*if*/
printf(%*c, 27 - pos, ' ');
printf(%s\n, desc);
}/*explain_option*/
#define xo explain_option
xo(f, file, FILENAME, output file name);
xo(F, format, c|t|p, output file format (custom, tar, plain text));
xo(i, ignore-version, NULL, proceed even when server version mismatches\n
pg_dump version);
xo(v, verbose, NULL, verbose mode);
xo(Z, compress, 0-9, compression level for compressed formats);
This is only a quick hack, I didn't care for _() and
explain_option() could be smarter about multi line descriptions,
but you get the idea ...
Servus
Manfred
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] Autocommit off and transaction isolation level
Hi all, I have come across some weird behavior in postgres concerning autocommit=off and setting the transaction isolation level. I have no explanation why things should work as they do, so I consider this a bug, no? With autocommit=on and normal begin; ... commit; block setting the transaction isolation level works fine: billing=# begin; BEGIN billing=# set transaction isolation level serializable; SET billing=# show transaction isolation level; TRANSACTION ISOLATION LEVEL - SERIALIZABLE (1 row) billing=# commit; COMMIT Now setting autocommit=off the set transaction isolation level command does not show any effect: billing=# set autocommit to off; SET billing=# set transaction isolation level serializable; SET billing=# select current_date; date 2003-01-02 (1 row) billing=# show transaction isolation level; TRANSACTION ISOLATION LEVEL - READ COMMITTED this should be SERIALIZABLE, no?? (1 row) billing=# commit; COMMIT Is it a bug? Regards, Michael Paesold ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL Password Cracker
I'll do that. Justin: What's the URL for the .pgpass stuff? So far I see mention of using SSL. That's two items to cover. Anything else? On Wed, 1 Jan 2003, Bruce Momjian wrote: Yes, I have been feeling we should do that. Justin pointed out just yesterday that .pgpass is only mentioned in libpq documentation, and in fact there is lots of stuff mentioned in libpq that releates to the other interfaces, so it should be pulled out and put in one place. Does anyone want to tackle this? --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: What do others think? I am not sure myself. There should definitely be someplace that recommends using SSL across insecure networks (if there's not already). But it doesn't seem to me to qualify as a FAQ entry. Somewhere in the admin guide seems more appropriate. Perhaps under Client Authentication? Maybe someone could even put together enough material to create a whole chapter on security considerations --- this is hardly the only item worthy of mention. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump.options.diff
Manfred Koizar [EMAIL PROTECTED] writes: Just another way to do it: #define xo explain_option xo(f, file, FILENAME, output file name); Perhaps better would be: #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%-27s %s\n, long, desc) #else #define xo(long,short,desc) printf(%-27s %s\n, short, desc) #endif xo(_(-f, --file=FILENAME), _(-f FILENAME), _(output file name)); which avoids putting a lot of smarts (read: restrictions) into the subroutine, but still keeps most of the other benefits, including: * keeping the segments of the description together in the source code, and rationally organized from a translation standpoint; * only one place to change to adjust the column width. Although it occurs to me that with the existing setup, it's possible for the translator to unilaterally alter the column width for the switches, which is something he'd definitely like to be able to do. Maybe we should not try to be cute, but just do #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif xo(_(-f, --file=FILENAME), _(-f FILENAME), _(output file name)); so that the column spacing remains under control of the translator. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Autocommit off and transaction isolation level
Michael Paesold [EMAIL PROTECTED] writes: Now setting autocommit=off the set transaction isolation level command does not show any effect: billing=# set autocommit to off; SET billing=# set transaction isolation level serializable; SET SET does not start a transaction block, so this will not work. You must use an explicit BEGIN before setting TRANSACTION ISOLATION LEVEL. You might instead set default_transaction_isolation to get the behavior I think you are looking for. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Autocommit off and transaction isolation level
On Thu, 2 Jan 2003, Tom Lane wrote: Michael Paesold [EMAIL PROTECTED] writes: Now setting autocommit=off the set transaction isolation level command does not show any effect: billing=# set autocommit to off; SET billing=# set transaction isolation level serializable; SET SET does not start a transaction block, so this will not work. You must use an explicit BEGIN before setting TRANSACTION ISOLATION LEVEL. You might instead set default_transaction_isolation to get the behavior I think you are looking for. The overall behavior appears to be against spec, but I figure this was discussed at the time the set transation was added. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Password Cracker
Dan Langille wrote: I'll do that. Justin: What's the URL for the .pgpass stuff? So far I see mention of using SSL. That's two items to cover. Anything else? Hi Dan, Very Cool. The URL for the .pgpass stuff is: http://developer.postgresql.org/docs/postgres/libpq-files.html :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Password Cracker
On Fri, 3 Jan 2003, Justin Clift wrote: Very Cool. The URL for the .pgpass stuff is: http://developer.postgresql.org/docs/postgres/libpq-files.html There is a typo on that page. First it talkes about the file .pgpass and then it says: chmod 0600 .pgaccess. I had no idea that one could store the passwords like this. This feature is something I'm going to use from now on (now that I know about it). -- /Dennis ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump.options.diff
- Original Message - From: Tom Lane [EMAIL PROTECTED] Sent: January 02, 2003 9:29 AM Maybe we should not try to be cute, but just do #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif xo(_(-f, --file=FILENAME), _(-f FILENAME), _(output file name)); so that the column spacing remains under control of the translator. Looks good to me, but there is still a little inconvenience of multiline option descriptions, and the above won't handle it nicely. If people agree with the above, can I go ahead and make corresponding changes? OR may be a whole generic option-formatting routine should be created; one for all the tools? ;-) Similar to explain_option() of Manfred, which will handle the mulitline, padding, and other stuff? (am being half serious here, but it could be an option) -s ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] [HACKERS] Cast your vote ...
Postgresql is first, now (51%, mysql 35%) regards Haris Peco On Thursday 02 January 2003 08:53, Daniel Kalchev wrote: Registration is easy, and pretty much anonymous... worth to promote our beloved database. :) Happy New Year, Daniel Marc G. Fournier said: Just got this in my mailbox: 2002 LinuxQuestions.org Members Choice Awards: http://www.linuxquestions.org/questions/showthread.php?s=78a8c06fbc1dcec d525 97decd6c56ad8threadid=39870 And we are way behind MySQL (like, d'ah!): http://www.linuxquestions.org/questions/poll.php?s=78a8c06fbc1dcecd52597 decd 6c56ad8action=showresultspollid=168 The problem, of course, is that you have to be a registered member to vote, so its not an 'open poll' ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Bug in pg_get_constraintdef (for deferrable
I think I initially forgot those options, and Stephans patch seems to be everything required -- though the psql display is a little more cluttered. pg_get_constraintdef should probably be looking at condeferrable and condeferred in the pg_constraint row it's looking at. Maybe something like the attached. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] pg_dump.options.diff
Serguei Mokhov [EMAIL PROTECTED] writes: Looks good to me, but there is still a little inconvenience of multiline option descriptions, and the above won't handle it nicely. True, a multiline description would have to look like xo(_(-f, --file=FILENAME), _(-f FILENAME), _(output file name\n more description)); Which is not great, but it doesn't seem completely unworkable either. And the translator can still adjust the column spacing without any code changes. may be a whole generic option-formatting routine should be created; one for all the tools? ;-) Similar to explain_option() of Manfred, which will handle the mulitline, padding, and other stuff? (am being half serious here, but it could be an option) The trouble I see there is that the layout --- in particular the column width --- would be embedded in such a routine and not alterable by simply replacing message texts. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Bug in pg_get_constraintdef (for deferrable
On 2 Jan 2003, Rod Taylor wrote: I think I initially forgot those options, and Stephans patch seems to be everything required -- though the psql display is a little more cluttered. IIRC, theoretically only initially immediate deferrable actually needs to specify both clauses (initially deferred guarantees deferrable and not deferrable doesn't need an initially at all). It seemed like that was getting too cute though for a quick patch. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Bug in pg_get_constraintdef (for deferrable
Rod Taylor [EMAIL PROTECTED] writes: I think I initially forgot those options, and Stephans patch seems to be everything required -- though the psql display is a little more cluttered. Yeah, it is. Could we improve that by having pg_get_constraintdef add text only when the setting isn't the default? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] BITMAP Index support (and other DSS info.)
Shahbaz == Shahbaz Chaudhary [EMAIL PROTECTED] writes: Shahbaz There are bound to be people in the academia (grad Shahbaz students, professors of CS, etc.) on this mailing list, Shahbaz yet I see few RDBMS courses using postgresql as an Shahbaz example. If people still have connections to Shahbaz universities, it would seem that inviting researchers to Shahbaz use PGSQL for their experiments will quickly make it Shahbaz comparable to Oracle/etc. This would be specifically At Berkeley, PostgreSQL is used for projects in the upper division undergraduate database systems class. At least it was used this past Fall, and we plan to use it in the Spring as well (I will be TA'ng). The projects involved using pg as a back-end and a small buffer replacement policy assignment. http://www-inst.eecs.berkeley.edu/~cs186/ In addition, we (the database systems research group) are using the PostgreSQL code base (7.2.1) to build TelegraphCQ, our new system to process continuous queries over data streams. Preliminary paper here: http://www.cs.berkeley.edu/~franklin/Papers/TCQcidr03.pdf No, it's not really close to a release yet ... :-) -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] why was libpq.so version bumped?
Hi! subject says it all, I guess. There is hardly no difference between 7.3 libpq and 7.3.1 libpq. Why the version shift? Isn't the only thing rectifying a version shift that there is a change in the API. Maybe there is, but I cannot find it. If there is a good reason, like say security, maybe I can persuade the FreeBSD port responsible to bring the port into the upcoming FreeBSD 5.0 release. The port freeze was introduced just before 7.3 was released, so nothing new will be admitted unless it is a security fix, more or less, which means FreeBSD 5.0 will ship with 7.2.3, which would be a disappointment... It is a PITA to relink every binary, so I guess I'll just keep the old lib around. Still, I could use a good explanation why the version shift was comitted. Cheers, Palle ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Upgrading rant.
It's that time of year again, when I remind everyone just how difficult life in the trenches with PostgreSQL can be, when the life in the trenches involves upgrades. If you don't want to read about it, then please hit DELETE in you e-mail (or nntp) client. I'll not get too vehement this time (well, I'll try not to), but I am continuously bombarded with requests for help in upgrading. These requests really bother me, particularly since I believe PostgreSQL is the finest Open Source database, period. I have attempted to help in this by building some older PostgreSQL versions on more modern Red Hat distributions; alas and alack, some relatively recent versions of PostgreSQL will simply not build on more recent Red Hat. Case in point: I tried to help out a fellow (Tony) who upgraded from Red Hat 7.1 (I believe) to Red Hat 8.0. Red Hat 8.0 includes PostgreSQL 7.2.2, and Red Hat 7.1 has PostgreSQL 7.1.something. Good thing he didn't go back to Red Hat 7.0 (PG 7.0). So I figured I'd roll a 7.1.3 RPMset for him to install onto Red Hat 8. It was very bad. It simply would not build -- I guess it's the gcc 3 stuff. He can't downgrade! (Really! Red Hat 8 upgrades more than just PostgreSQL -- the upgrade wiped out libraries that PostgreSQL 7.1 on the previous Red Hat needed to function. The RPM installation of PostgreSQL 7.1 from the previous Red Hat would NOT reinstall.). So this man is up the creek, without a paddle, in a chicken-wire canoe WRT his 7.1 data. This is unacceptable. THIS DOESN'T HAPPEN WITH MySQL. I'm more than a little perturbed that, as MySQL adds features, it doesn't make you upgrade your database each release: it simply doesn't allow the features your database doesn't support. You can then migrate each table as you need the new features. While he really should have read our documentation and been a little more careful, we shouldn't be so anal about upgradability, either. I know it's been hashed to death, but the problem isn't going away anytime soon. I'm afraid that this is going to become a key feature, and one we are missing, but our primary Open Source competition isn't missing. And I _know_ some are just going to fingerpoint and blame Red Hat. Any such replies I will rather quickly redirect to /dev/null, as it isn't Red Hat's fault we can't do a sane upgrade. Others are going to handwave and say 'we're so advanced we can't upgrade', and still others are going to say 'Oracle can't do it; why whould we?' These replies also will meet the bottomless bit bucket -- I'm not interested in arguing whether we should allow good upgrading or not, so don't bother trying to convince me upgrades aren't important, or 'dump/initdb/restore IS an upgrade!' I am interested in sane discussion of how to make it happen. Red Hat at least has a data dumper, but even at that it isn't an easy task to upgrade. (source.redhat.com/rhdb) I believe, as I have said before, that the biggest problem preventing easy upgrades is our tight coupling of system catalog data with user data, in the same tablespace. If the system catalog data were less tightly coupled, then it might be an easier job. I also know, from the last time this was discussed, that drawing the line between 'system' and 'user' data is very difficult due to our highly extensible nature. I thought the last time through would be the _last_ time through -- but I also thought I'd be able to build older PostgreSQL packages for newer dists, which would prevent much of this problem. (OS upgrade hosed your PostgreSQL? Here's packages for your old PostgreSQL built for your shiny new OS!) In my opinion, upgrading shouldn't be something a user should have to even think about. It should just happen. Kindof like 'space reuse should just happen' too Postmaster should have a fallback mode when it starts up in PGDATA where PGVERSION is postmaster version. This would take care of ninety percent or more of upgrades -- the user can dump and restore later if need be, or a migration tool can be written, or... this is where I'd like to see more discussion and less of a back burner approach. And I'd love to see someone who has the time to do so (not me) grab this bull by the horns and make it happen. (Yes, I realize the use of certain of our extensibility features will be impossible to upgrade cleanly, but that's what you get when you allow embedded C code in the backend.) I'm talking about the majority of cases where a user simply has some relational data (no custom functions, types, or operators) that is critical to their business that they need to move over QUICKLY. (dump/restore is anything but quick). And some are going to do this upgrade on their production server, regardless of how many times we tell people not to do so. Not every entity who uses PostgreSQL has on staff a professional DBA and an extra server to do the migration with. MySQL is even touting the ability to
Re: [HACKERS] [GENERAL] Cast your vote ...
On Thu, 2 Jan 2003, Marc G. Fournier wrote: Just got this in my mailbox: 2002 LinuxQuestions.org Members Choice Awards: http://www.linuxquestions.org/questions/showthread.php?s=78a8c06fbc1dcecd52597decd6c56ad8threadid=39870 And we are way behind MySQL (like, d'ah!): http://www.linuxquestions.org/questions/poll.php?s=78a8c06fbc1dcecd52597decd6c56ad8action=showresultspollid=168 The problem, of course, is that you have to be a registered member to vote, so its not an 'open poll' ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Open Poll? Its free to register, so really its to try and stop people voting twice. They don't even want that much data just your E-Mail address. (The rest is optional) The problem with Web Polls is that people can always vote more than once making any result totally meaning less what ever you do. Ensuring an election is anoumous, free and fare is VERY difficult. Peter Childs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] Cast your vote ...
Yeah, the registration was painless and enough options to disable it annoying you. Count my vote cast for PostgreSQL. I encourage everyone else to do the same. In the big picture, marketing statements like this survey mean alot more than most technical folks want to acknowledge. Please vote for your favorite database. Charlie Peter Childs wrote: On Thu, 2 Jan 2003, Marc G. Fournier wrote: Just got this in my mailbox: 2002 LinuxQuestions.org Members Choice Awards: http://www.linuxquestions.org/questions/showthread.php?s=78a8c06fbc1dcecd52597decd6c56ad8threadid=39870 And we are way behind MySQL (like, d'ah!): http://www.linuxquestions.org/questions/poll.php?s=78a8c06fbc1dcecd52597decd6c56ad8action=showresultspollid=168 The problem, of course, is that you have to be a registered member to vote, so its not an 'open poll' ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Open Poll? Its free to register, so really its to try and stop people voting twice. They don't even want that much data just your E-Mail address. (The rest is optional) The problem with Web Polls is that people can always vote more than once making any result totally meaning less what ever you do. Ensuring an election is anoumous, free and fare is VERY difficult. Peter Childs ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Charles H. Woloszynski ClearMetrix, Inc. 115 Research Drive Bethlehem, PA 18015 tel: 610-419-2210 x400 fax: 240-371-3256 web: www.clearmetrix.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump.options.diff
- Original Message - From: Tom Lane [EMAIL PROTECTED] Sent: January 02, 2003 1:58 PM Serguei Mokhov [EMAIL PROTECTED] writes: Looks good to me, but there is still a little inconvenience of multiline option descriptions, and the above won't handle it nicely. True, a multiline description would have to look like xo(_(-f, --file=FILENAME), _(-f FILENAME), _(output file name\n more description)); Which is not great, but it doesn't seem completely unworkable either. And the translator can still adjust the column spacing without any code changes. Well, it's better than before and solves *my* (and other translators') problem. Now, this: #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif seems relatively generic, so it could be used by more than one tool. I searched for 'util' the source tree to see a more or less logical place to put it. I got a whole bunch of .*util.* files, but none of them seems appropriate enough because they all specific to some other tool or smth else. Is pushing it up to c.h an option, or it'll become too polluted? Where should I place it? may be a whole generic option-formatting routine should be created; one for all the tools? ;-) Similar to explain_option() of Manfred, which will handle the mulitline, padding, and other stuff? (am being half serious here, but it could be an option) The trouble I see there is that the layout --- in particular the column width --- would be embedded in such a routine and not alterable by simply replacing message texts. True, but what would be wrong by having an argument for the column width? -s ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] new project - PostgresSQL based voting script
See http://polls.unixathome.org/ Goal: create a voting script which uses PostgreSQL to store the data. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] Cast your vote ...
On 2 Jan 2003 at 7:53, Charles H. Woloszynski wrote: Yeah, the registration was painless and enough options to disable it annoying you. Count my vote cast for PostgreSQL. I encourage everyone else to do the same. In the big picture, marketing statements like this survey mean alot more than most technical folks want to acknowledge. Please vote for your favorite database. Coincidentally, I've just started up a voting script project... see http://polls.unixathome.org/ -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump.options.diff
Serguei Mokhov [EMAIL PROTECTED] writes: Now, this: #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif seems relatively generic, so it could be used by more than one tool. But there's no good place to put it. I'd say just stick it into each tool; it's no worse than repeating the existence of a usage() subroutine in each tool. Is pushing it up to c.h an option, I'd vote against that. The trouble I see there is that the layout --- in particular the column width --- would be embedded in such a routine and not alterable by simply replacing message texts. True, but what would be wrong by having an argument for the column width? The translator would have no control over such an argument --- at least not without some mechanism outside the .po files. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] Cast your vote ...
On Thu, Jan 02, 2003 at 03:07:48PM -0500, Dan Langille wrote: else to do the same. In the big picture, marketing statements like this survey mean alot more than most technical folks want to acknowledge. The figures would be a lot more interesting anyway if people bothered to correlate results with user bases. A vote from someone who knows several of the contending products means a lot more to me than one from someone who hasn't seen aything else. Coincidentally, I've just started up a voting script project... see http://polls.unixathome.org/ Does it support hanging chads? Jeroen ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] Cast your vote ...
On 2 Jan 2003 at 21:30, Jeroen T. Vermeulen wrote: Coincidentally, I've just started up a voting script project... see http://polls.unixathome.org/ Does it support hanging chads? Now is the time to decide that -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Bug in pg_get_constraintdef (for deferrable constraints)
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. It also will be backpatched. --- Stephan Szabo wrote: On Wed, 1 Jan 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I see the values being stored on constriant creation, but not being used anywhere: I believe the values that actually get inspected at runtime are the tgdeferrable and tginitdeferred fields in pg_trigger. The columns in pg_constraint are just copies of these. It is not real clear to me whether it should be allowed to alter the deferrability status of a foreign-key constraint --- is that in the spec? The big problem is that while pg_dump's dump_trigger() looks at tginitdeferred and dumps accordingly, pg_get_constraintdef doesn't look at tginitdeferred, and therefore doesn't record the requirement as part of ALTER TABLE ADD CONSTRAINT. pg_get_constraintdef should probably be looking at condeferrable and condeferred in the pg_constraint row it's looking at. Maybe something like the attached. Content-Description: [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Upgrading rant.
On Thu, Jan 02, 2003 at 07:26:06PM -0500, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: replies I will rather quickly redirect to /dev/null, as it isn't Red Hat's fault we can't do a sane upgrade. I think you're wasting your time trying to hold us to a higher standard of backwards-compatibility than is maintained by the OSes and tools we must sit on top of. Case in point: even though the Debian upgrade scripts have occasionally given me a near-heart attack by claiming that they didn't succcessfully upgrade when they did, I've never had this problem. Is this because Oliver is smarter than you? Or Debian is 'superior'? No, it's because _incremental upgradability_ is _the_ design goal for the Debian distribution. Lots of other stuff may work better on RedHat (auto hardware detection, etc.) but this is the design case for Debian, so the facilities are mostly there for Oliver to use to do incremental, rollbackable, upgrades. What does that mean for PostgreSQL? Perhaps Tom's right: you can't fix it in the program if the underlying system doesn't support it. Ross ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] targetlist functions proposals (was SETOF input parameters)
(moved from PATCHES back to HACKERS) Tom Lane wrote: Oh, you're thinking about the multi-column aspect of it, not the multi-row aspect. You really ought to keep those strictly separate; their design and implementation problems are quite different IMHO. I find it quite confusing to refer to both cases as SRFs. [...snip...] Before that, though, you'd better put forward a workable user interface for this; I'd wonder in particular what the names of the expanded-out columns will be, and whether they'd be accessible from places that can normally see output column names (such as ORDER BY). And what if a multi-column function appears in the targetlist of a sub-SELECT? I've put some thought into *two* proposals for how targetlist functions should behave -- one for a function that returns multiple rows, and one for a function that returns multiple columns. The need for this was highlighted recently when I submitted a proposal for array utility functions; see: http://archives.postgresql.org/pgsql-hackers/2002-12/msg00461.php At this point I don't have a clear idea how the latter would be implemented (or if it even *can be* implemented with reasonable effort), but I wanted to try to get agreement on the interface behavior before getting too caught up in how to make it work. I think the former is reasonably straightforward (but could well be wrong). This is fairly long, so if you're not interested please delete now and accept my apologies :-) Proposals are below. Thoughts? Thanks, Joe = User interface proposal for multi-row function targetlist entries = 1. Only one targetlist entry may return a set. 2. Each targetlist item (other than the set returning one) is repeated for each item in the returned set. Examples illustrating the need (these work on cvs HEAD): CREATE TABLE bar(f1 int, f2 text, f3 int); INSERT INTO bar VALUES(1, 'Hello', 42); INSERT INTO bar VALUES(2, 'Happy', 45); CREATE TABLE foo(a int, b text); INSERT INTO foo VALUES(42, 'World'); INSERT INTO foo VALUES(42, 'Everyone'); INSERT INTO foo VALUES(45, 'Birthday'); INSERT INTO foo VALUES(45, 'New Year'); CREATE OR REPLACE FUNCTION getfoo(int) RETURNS SETOF text AS ' SELECT b FROM foo WHERE a = $1 ' language 'sql'; regression=# SELECT f1, f2, getfoo(f3) AS f4 FROM bar; f1 | f2 |f4 +---+-- 1 | Hello | World 1 | Hello | Everyone 2 | Happy | Birthday 2 | Happy | New Year (4 rows) Note that this is exatly how things currently work, i.e. there is no restriction to the number of set returning targetlist entries. This lack of restriction leads to strange and unexpected results (at least IMHO). Continuing the example: CREATE TABLE foo2(a int, b text); INSERT INTO foo2 VALUES(42, ''); INSERT INTO foo2 VALUES(42, ''); INSERT INTO foo2 VALUES(42, ''); INSERT INTO foo2 VALUES(45, ''); CREATE OR REPLACE FUNCTION getfoo2(int) RETURNS SETOF text AS ' SELECT b FROM foo2 WHERE a = $1 ' language 'sql'; Now, what *should* the following return if we allow multiple set returning functions in the targetlist? Here's what it currently does: regression=# SELECT f1, f2, getfoo(f3) AS f4, getfoo2(f3) AS f5 FROM bar; f1 | f2 |f4| f5 +---+--+-- 1 | Hello | World| 1 | Hello | Everyone | 1 | Hello | World| 1 | Hello | Everyone | 1 | Hello | World| 1 | Hello | Everyone | 2 | Happy | Birthday | 2 | Happy | New Year | (8 rows) Not very useful as there is no way to prevent the apparent cartesian join. But now try: TRUNCATE TABLE foo2; INSERT INTO foo2 VALUES(42, ''); INSERT INTO foo2 VALUES(42, ''); INSERT INTO foo2 VALUES(45, ''); INSERT INTO foo2 VALUES(45, ''); regression=# SELECT f1, f2, getfoo(f3) AS f4, getfoo2(f3) AS f5 FROM bar; f1 | f2 |f4| f5 +---+--+-- 1 | Hello | World| 1 | Hello | Everyone | 2 | Happy | Birthday | 2 | Happy | New Year | (4 rows) Hmmm, what happened to that cartesian join? Under the proposal the two previous scenarios are disallowed with an ERROR. User interface proposal for multi-column function targetlist entries 1. One, or more, targetlist entries may be a multi-column (composite) type. 2. For functions declared to return a named composite type, the column names and types are as prescribed by the type unless overridden in an alias definition. 3. For functions declared to return a record type, a column definition list would be required as an alias at runtime. 4. Any alias provided for a composite returning function must match the number of columns returned, and types if provided. 5. The composite
Re: [HACKERS] pg_dump.options.diff
- Original Message - From: Tom Lane [EMAIL PROTECTED] Sent: January 02, 2003 3:20 PM #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif seems relatively generic, so it could be used by more than one tool. But there's no good place to put it. I'd say just stick it into each tool; it's no worse than repeating the existence of a usage() subroutine in each tool. It ended up being in dumputils.h Attached a patch for pg_dump(all) and pg_restore eliminating dupes in option descriptions as per above xo technology. Please review and apply if there are no too many objections. thank you, -s pg_dump.options2.diff Description: Binary data ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Password Cracker
Bruce Momjian writes: Yes, I have been feeling we should do that. Justin pointed out just yesterday that .pgpass is only mentioned in libpq documentation, and in fact there is lots of stuff mentioned in libpq that releates to the other interfaces, so it should be pulled out and put in one place. It is difficult to make out which place that would be. You can duplicate the information in every place where an interface or tool that uses libpq is documented, but that doesn't seem to be conceptually superior. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_dump.options.diff
Serguei Mokhov [EMAIL PROTECTED] writes:
But there's no good place to put it. I'd say just stick it into each
tool; it's no worse than repeating the existence of a usage()
subroutine in each tool.
It ended up being in dumputils.h
I really don't like putting a macro with a name as short as xo into a
header file, even one of relatively narrow scope. It's too likely to
create weird conflicts. My inclination is to make the coding be more
like
static void
usage(void)
{
#if defined(HAVE_GETOPT_LONG)
#define xo(longOption,shortOption,desc) printf(%s %s\n, longOption, desc)
#else
#define xo(longOption,shortOption,desc) printf(%s %s\n, shortOption, desc)
#endif
... lots of xo() calls ...
#undef xo
}
This gives us the convenience of a very short name within the usage()
subroutines, while not polluting the namespace for everyplace else in
these utilities.
As I said before, duplicating the definition of xo() in each file that
uses it doesn't bother me a bit; it's too simple for that to be a
significant objection.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PostgreSQL Password Cracker
Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian writes: Yes, I have been feeling we should do that. Justin pointed out just yesterday that .pgpass is only mentioned in libpq documentation, and in fact there is lots of stuff mentioned in libpq that releates to the other interfaces, so it should be pulled out and put in one place. It is difficult to make out which place that would be. You can duplicate the information in every place where an interface or tool that uses libpq is documented, but that doesn't seem to be conceptually superior. Duplicating this info is clearly a losing proposition. But I think Bruce is envisioning restructuring the documentation of libpq to separate out the parts that are only interesting to a programmer using libpq from the parts that are interesting to a user of a libpq-based program (for example, all the info about environment variables, conninfo string syntax, and .pgpass). Then the docs for interfaces and tools could cross-reference the externally visible behavior section of the libpq docs --- and this section would make sense to an end user, without drowning him in details he doesn't care about. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PostgreSQL Password Cracker
Dennis Björklund wrote: On Fri, 3 Jan 2003, Justin Clift wrote: Very Cool. The URL for the .pgpass stuff is: http://developer.postgresql.org/docs/postgres/libpq-files.html There is a typo on that page. First it talkes about the file .pgpass and then it says: chmod 0600 .pgaccess. I had no idea that one could store the passwords like this. This feature is something I'm going to use from now on (now that I know about it). I looked at CVS and the fix is in CVS head, but not in 7.3.X. I applied it only to CVS head because I wasn't sure if were were backpatching docs into CVS. I was later told we were rebuilding 7.3.X docs every night so we should backpatch docs. Also, does anyone know why the development docs are 7.3.1? http://developer.postgresql.org/docs/postgres/index.html Seems if it is on the developers page, it should be CVS head? Wasn't that supposed to build on demand? I don't think that is working. Perhaps it took too much CPU. The docs on my machine are based on CVS head and do build on demand: http://candle.pha.pa.us/main/writings/pgsql/sgml Both links are on the developers page. Is someone working to get 7.3.1 announced on our main web site? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Password Cracker
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian writes: Yes, I have been feeling we should do that. Justin pointed out just yesterday that .pgpass is only mentioned in libpq documentation, and in fact there is lots of stuff mentioned in libpq that releates to the other interfaces, so it should be pulled out and put in one place. It is difficult to make out which place that would be. You can duplicate the information in every place where an interface or tool that uses libpq is documented, but that doesn't seem to be conceptually superior. Duplicating this info is clearly a losing proposition. But I think Bruce is envisioning restructuring the documentation of libpq to separate out the parts that are only interesting to a programmer using libpq from the parts that are interesting to a user of a libpq-based program (for example, all the info about environment variables, conninfo string syntax, and .pgpass). Then the docs for interfaces and tools could cross-reference the externally visible behavior section of the libpq docs --- and this section would make sense to an end user, without drowning him in details he doesn't care about. Right. I think as a minimum, we need to move the libpq environment variables and, as Justin said, the .pgpass stuff out into its own section, and reference that from libpq and other interfaces/applications. We have had several reports of folks not knowing it, and it is obvious is it because the info is inside a C library API chapter. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Password Cracker
Bruce Momjian [EMAIL PROTECTED] writes: Also, does anyone know why the development docs are 7.3.1? Because it was pointed to that branch during the 7.3 beta cycle. It needs to be repointed to CVS tip. I dunno how to do so, however. Is someone working to get 7.3.1 announced on our main web site? I would like to think that someone in either the -advocacy or webmaster groups will get around to that sometime soon ;-) regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Upgrading rant.
Lamar Owen [EMAIL PROTECTED] writes: So I figured I'd roll a 7.1.3 RPMset for him to install onto Red Hat 8. It was very bad. It simply would not build -- I guess it's the gcc 3 stuff. If you don't know *exactly* why it doesn't build, I don't think you should be blaming us for it. (FWIW, I just tried to build 7.1 branch on RHL 8.0 --- the main problem seems to be that 7.1's configure isn't expecting multiline output from gcc --version, and it produces a PG_VERSION_STR definition that's missing a trailing quote. There are some other issues, none that look very difficult to fix, all indicative of incompatible changes in either gcc or system include files.) THIS DOESN'T HAPPEN WITH MySQL. Oh? Do they have a crystal ball that lets them predict incompatible future platform changes? (I'm not very sure I believe your assertion above, anyway. We are painfully aware of our own compatibility issues, but I wonder how many people on this list pay close enough attention to MySQL to know what their version-to-version compatibility track record *really* is.) I thought the last time through would be the _last_ time through -- but I also thought I'd be able to build older PostgreSQL packages for newer dists, which would prevent much of this problem. You could do so if you were willing to track the platform changes. 7.1 isn't hopelessly broken for RHL 8.0, but it's definitely suffering bit rot. Someone would have to expend effort on updating obsolete branches, if we wanted them to keep working in the face of incompatible platform changes. And I'd love to see someone who has the time to do so (not me) grab this bull by the horns and make it happen. Well, this is exactly the issue: someone would have to put substantial amounts of time into update mechanisms and/or maintenance of obsolete versions, as opposed to features, performance improvements, or bug fixes. Personally, I feel that if we weren't working as hard as we could on features/performance/bugfixes, the upgrade issue would be moot because there wouldn't *be* any reason to upgrade. So I'm not planning to redirect my priorities. But this is an open source project and every developer gets to set their own priorities. If you can persuade someone to put their time into that, go for it. And I _know_ some are just going to fingerpoint and blame Red Hat. Any such replies I will rather quickly redirect to /dev/null, as it isn't Red Hat's fault we can't do a sane upgrade. I think you're wasting your time trying to hold us to a higher standard of backwards-compatibility than is maintained by the OSes and tools we must sit on top of. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
