Re: [HACKERS] Version Numbering
On Sat, Aug 21, 2010 at 1:00 PM, Greg Stark gsst...@mit.edu wrote: On Sat, Aug 21, 2010 at 4:29 AM, Sergio A. Kessler sergiokess...@gmail.com wrote: on every single planet of the universe, except the one called postgrearth, whose inhabitants breathe sql and eat messages from postgresql mailing lists... :-) most people I know, think 8.1 is just 8.0 with some fixes... Really? is Linux 2.6 just 2.5 with some fixes? Glibc 2.Was Windows 3.5 just 3.4 with some fixes? Gnome 2.28 just 2.27 with some fixes? really !, they don't have *any* idea of the version of the kernel, they know about redhat 4, redhat 5 and so on... glibc ? what is that ? is not something they use... :-) sure, we know better, but the common guy in the computer field, does not read every mailing list on earth... In fact perusing dpkg -l output the *only* software package I find that bumps the major version every single release is Emacs. It stands out as an outlier as soon as you say version 23 -- and that was despite a hiatus when version 18.59 was the newest release for years. imho, emacs does it rigth... regards, /sak -- 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] Version Numbering
The current system give people the completely false impression that 7.0 and 7.4 are somehow similar. On what planet? on every single planet of the universe, except the one called postgrearth, whose inhabitants breathe sql and eat messages from postgresql mailing lists... :-) most people I know, think 8.1 is just 8.0 with some fixes... regards, /sak -- 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] Specific names for plpgsql variable-resolution control options?
hi tom, sorry for the out-of-the-blue email (I'm not on the list)... On Nov 6, 2009, at 12:21 PM, Tom Lane wrote: I believe we had consensus that plpgsql should offer the following three behaviors when a name in a SQL query could refer to either a plpgsql variable or a column from a table of the query: * prefer the plpgsql variable (plpgsql's historical behavior) * prefer the table column (Oracle-compatible) * throw error for the ambiguity (to become the factory default) and that we wanted a way for users to select one of these behaviors at the per-function level, plus provide a SUSET GUC to determine the default behavior when there is not a specification in the function text. What we did not have was any concrete suggestions for the name or values of the GUC, nor for the exact per-function syntax beyond the thought that it could look something like the existing '#option dump' modifier. The code is now there and ready to go, so I need a decision on these user-visible names in order to proceed. Anyone have ideas? is this become configurable somehow, how would I know that my code work as expected when I distribute my code ? one option is to put foo_variable_conflict = error throughout the code, which can be thousands of lines, which is not nice just to be sure my code works as expected no matter what... (setting a general GUC can interfere with another code, which presumes different things) and moreover, is a burden for postgresql that should be supporting 'foo_variable_conflict' in the foreseeable future... IMO, postgres should stick with one option (+1 for error) and be done with this, just one simple rule to rule them all... and with this, there is no need to band-aid the code just in case... regards, /sergio -- 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] MySQL to PostgreSQL for SugarCRM
dennis, look at vtiger crm (http://www.vtiger.com) vtiger is a fork of sugarcrm and are 100% commited to open source. (unlike sugar, who offer the full version only for purchase) and they actively want to support more databases. regards, /sak Denis Lussier wrote: At EnterpriseDB we're doing a little project along these lines. In our lab, and soon for our company, we are running SugarCRM on EDB-Postgres. Alas you say, but SugarCRM only supports MySQL: EDB ships a nifty java based ETL tool with our product that is 99.5% based on the Enhydra Octopus LGPL project. This allows for easily converting schema and data from a populated MySQL SugarCRM database into Postgres. Then we hacked the PHP code of SugarCRM for a couple days and it is now working just fine on EDB-Postgres. I think that whenever we come across an Open Source (or even a commercial\proprietary product) out there that supports MySQL, but not PostgreSQL... We need to work collectively as a group to make it shamefully simple for the project to work with PostgreSQL also. SugarCRM has 250,000 downloads and every single one of those customers is guaranteed to be introduced to MySQL and only MySQL. --Luss PS1 Yes, we are going to try and work with the SugarCRM folks and get Postgres supported natively without customers having to hack the way we did to get it working. PS2 I've hired many interns for summer and/or co-op jobs over the years. The trick is to give them something interesting to do AND pay them a little more than they can make flipping burgers. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] More DROP COLUMN
chris, have you looked at how sapdb (http://www.sapdb.org) does this ? /sergio ps: IANAL Christopher Kings-Lynne [EMAIL PROTECTED] escribió en el mensaje [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... OK, DROP COLUMN now seems to work perfectly. All the old test cases that failed now work fine. However, I'm not happy with the way dropped columns are renamed. I want to give them a name that no-one would ever want to use as a legit column name. I don't like this behaviour: test=# create table test (a int4, b int4); CREATE TABLE test=# alter table test drop a; ALTER TABLE test=# select dropped_1 from test; ERROR: Attribute dropped_1 not found test=# alter table test add dropped_1 int4; ERROR: ALTER TABLE: column name dropped_1 already exists in table test It's a bit confusing, hey? What should we do about it? Maybe I could make ADD COLUMN give this message instead for dropped columns? ERROR: ALTER TABLE: column name dropped_1 is a dropped column in table test ... or something ... We could name the fields dropped_x sort of thing perhaps Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] alter database without shutting down !?
first, congratulations to all for the 7.1 release, good work. second, I've found (some years ago to be honest) that pgsql can ALTER TABLE while the table is widely available for all users... this strike me as pretty bad/dangerous/confusing/messy (even from the POV of implementation) should I supposed to do something like: ALTER DATABASE CLOSE or ALTER DATABASE SHUTDOWN [options] (simil oracle) before doing changes to the definition of tables ? someone can say this is a feature, don't think so, even then I think that ALTER TABLE DROP COLUMN could be implemented a *lot* more easily with this method. (and requiring this operation to enter DDL sound very logical) regards, sergio _ Lo probaste? Correo gratis y para toda la vida en http://correo.yahoo.com.ar ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
