Re: [HACKERS] Version Numbering

2010-08-22 Thread Sergio A. Kessler
On Sat, Aug 21, 2010 at 1:00 PM, Greg Stark wrote:
 On Sat, Aug 21, 2010 at 4:29 AM, Sergio A. Kessler 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...


Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Re: [HACKERS] Version Numbering

2010-08-21 Thread Sergio A. Kessler
 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...


Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Re: [HACKERS] Specific names for plpgsql variable-resolution control options?

2009-11-07 Thread Sergio A. Kessler
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
 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'

 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...


Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Re: [HACKERS] MySQL to PostgreSQL for SugarCRM

2005-08-04 Thread Sergio A. Kessler

dennis, look at vtiger crm (

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.


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.
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


2002-07-15 Thread Sergio A. Kessler

chris, have you looked at how sapdb (
does this ?


Christopher Kings-Lynne [EMAIL PROTECTED] escribió en el

 DROP COLUMN now seems to work perfectly.  All the old test cases that
 now work fine.

 However, I'm not happy with the way dropped columns are renamed.  I want
 give them a name that no-one would ever want to use as a legit column
 I don't like this behaviour:

 test=# create table test (a int4, b int4);
 test=# alter table test drop a;
 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

 It's a bit confusing, hey?

 What should we do about it?

 Maybe I could make ADD COLUMN give this message instead for dropped

 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


 ---(end of broadcast)---
 TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

---(end of broadcast)---
TIP 6: Have you searched our list archives?

[HACKERS] alter database without shutting down !?

2001-04-14 Thread Sergio A. Kessler

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 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)


Lo probaste?
Correo gratis y para toda la vida en

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])