Re: [HACKERS] v7.3.1 psql against a v7.2.x database ...
Christopher Kings-Lynne wrote: With ever more larger businesses adopting PostgreSQL, and that leading on to more places having several versions of PostgreSQL in operation simultaneously (i.e. development vs production) we're probably going to need to give psql the ability to handle whichever version of the PG backend it happens to connect to. Marc's suggestion of breaking psql into it's own sub-project makes good sense from that point of view. Hey, good point. Giving psql the ability to handle multiple backend versions could be done in a number of ways. Subproject or not, why don't we just rearrange psql to dynamically load a library of functions, eg: libpsql72.so libpsql73.so etc... And in them you have functions like: printTableDef(); printViewDef(); etc... Is this very different from how it's done at present? :-) Regards and best wishes, Justin Clift Chris -- 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 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] Can we revisit the thought of PostgreSQL 7.2.4?
Lamar Owen [EMAIL PROTECTED] writes: ... Why? If a user doesn't need the features of 7.x.x, and the codebase is working well for him/her, why should said user/DBA feel compelled to go through who knows what mechanations to upgrade to the latest version? Because there are unfixable bugs in the older versions. I see very little point in issuing security updates that fix individual buffer overruns, when anyone who has the SQL-level access needed to trigger one of those overruns can equally easily do select cash_out(2). The only fix for that is an upgrade to 7.3. I don't by any means have a problem with Red Hat issuing maintenance releases against old versions (nor, as I said, do I have any objection to a 7.2.4 community release; I just said it wasn't my decision to make). What I am questioning is the value of fixing some security holes when there are bigger, unfixable ones right next door. It wastes time that could be spent on other work, and it may give DBAs a false sense of security. Sure I'm safe; I just got the latest security patch from Red Hat, so my 6.5.3 Postgres must be bulletproof now! 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
[HACKERS] constraint defaults still print
Remember how we made DEFERRABLE/DEFERRED not print if the constraint was the default. Shouldn't we do the same for MATCH and ON UPDATE/ON DELETE sections of the constraint in pg_get_constraintdef()? Doing \d I see: test= \d sales Table public.sales Column | Type | Modifiers ---+-+--- product_id| integer | not null store_id | integer | not null quantity_sold | integer | not null date_time_of_sale | date| not null Foreign Key constraints: $1 FOREIGN KEY (product_id) REFERENCES products(product_id) ON UPDATE NO ACTION ON DELETE NO ACTION, $2 FOREIGN KEY (store_id) REFERENCES stores(store_id) ON UPDATE NO ACTION ON DELETE NO ACTION If NO ACTION is the default, is there a need to print them? This would also shorten pg_dump output. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
On Saturday 18 January 2003 11:13, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: ... Why? If a user doesn't need the features of 7.x.x, and the codebase is working well for him/her, why should said user/DBA feel compelled to go through who knows what mechanations to upgrade to the latest version? Because there are unfixable bugs in the older versions. I see very little point in issuing security updates that fix individual buffer overruns, when anyone who has the SQL-level access needed to trigger one of those overruns can equally easily do select cash_out(2). The only fix for that is an upgrade to 7.3. And the cure might be worse than the disease; that is my point. It wastes time that could be spent on other work, and it may give DBAs a false sense of security. Sure I'm safe; I just got the latest security patch from Red Hat, so my 6.5.3 Postgres must be bulletproof now! Red Hat issued a very detailed synopsis of what was fixed. Also, one man's wasted time is another man's time well spent. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] constraint defaults still print
I vote for not showing 'NO ACTION', so long as it's the SQL standard default... Chris On Sat, 18 Jan 2003, Bruce Momjian wrote: Remember how we made DEFERRABLE/DEFERRED not print if the constraint was the default. Shouldn't we do the same for MATCH and ON UPDATE/ON DELETE sections of the constraint in pg_get_constraintdef()? Doing \d I see: test= \d sales Table public.sales Column | Type | Modifiers ---+-+--- product_id| integer | not null store_id | integer | not null quantity_sold | integer | not null date_time_of_sale | date| not null Foreign Key constraints: $1 FOREIGN KEY (product_id) REFERENCES products(product_id) ON UPDATE NO ACTION ON DELETE NO ACTION, $2 FOREIGN KEY (store_id) REFERENCES stores(store_id) ON UPDATE NO ACTION ON DELETE NO ACTION If NO ACTION is the default, is there a need to print them? This would also shorten pg_dump output. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Namespace/Table Visibility Behavior Issues
Assume a database with a couple of namespaces. Give two of these namespaces the names test_1 and test_2. Under these namespaces create a couple of tables with the names: example, example_2, example_3. set search_path to test_1, test_2; In the psql client, using a standard \d you will only see the namespace test_1 listed and the tables underneath that. test_2 will not be visible due to the fact they fail the pg_table_is_visible() check. I am not sure that is wise to do the pg_table_is_visible check on those commands. In my humble opinion, those commands are for understanding the layout/structure/nature of the database. If you can't see all your namespaces that you set in your search_path then it could distort ones understanding of the database. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Heading to Atlanta
I am heading to Atlanta for the one week training class. We have thirteen people signed up, and I think that is a good number. I return on Friday, but leave again on Wednesday for two weeks in Tokyo and Brussels, returning February 11. I should have connectivity for most of this period, but it will not be consistent. If you want to put out a 7.2.4 or 7.3.2, it would be ideal if it was after this Friday but before I leave for two weeks. However, I can still package up a release while on the road. As far as patches, I will probably not apply much while I am away for fear that I will apply a patch that needs to be backed out quickly. If I find I do have reliable connectivity, I will be more aggressive about patch applications. Tom has done a great job in the past while I was away, so he is welcome to continue that. -- 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 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] Heading to Atlanta
On Sunday 19 January 2003 01:16, Bruce Momjian wrote: I am heading to Atlanta for the one week training class. We have thirteen people signed up, and I think that is a good number. Atlanta, huh. You'll be less than four hours from me. I lived and worked (and went to school) in Atlanta from 1986 through 1989. Enjoy the light traffic, Bruce... :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Namespace/Table Visibility Behavior Issues
D. Hageman [EMAIL PROTECTED] writes: I am not sure that is wise to do the pg_table_is_visible check on those commands. In my humble opinion, those commands are for understanding the layout/structure/nature of the database. If you can't see all your namespaces that you set in your search_path then it could distort ones understanding of the database. What would you have it do --- list tables that you cannot actually access without qualification? That doesn't seem like an improvement to me. You could write \d *.* to see everything, or \d test_1.* and \d test_2.* to see the full contents of those two schemas. But ISTM that \d without any schema qualification should only show tables that you can access without any schema qualification. 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])
