On Wed, Sep 23, 2009 at 4:21 PM, D'Arcy J.M. Cain da...@druid.net wrote:
In any case, I have a strong philosophical objection to using the same
name to refer to two different things regardless of any operational
issues. The manager.firstname and employee.firstname are not the same
thing and
Hi,
...
code, even that is not needed, as the columns are returned in the order
specified so code /knows/ that the first column isname from /this/
table and the other column withname is from /that/ table).
Unless you get a dictionary return.
In any case, I have a strong philosophical
On Thu, 24 Sep 2009 08:49:02 -0400
Joe Riopel goo...@gmail.com wrote:
On Wed, Sep 23, 2009 at 4:21 PM, D'Arcy J.M. Cain da...@druid.net wrote:
In any case, I have a strong philosophical objection to using the same
name to refer to two different things regardless of any operational
issues.
On Thu, 24 Sep 2009 15:03:26 +0200
Tino Wildenhain t...@wildenhain.de wrote:
In any case, I have a strong philosophical objection to using the same
name to refer to two different things regardless of any operational
issues. The manager.firstname and employee.firstname are not the same
On Tue, 22 Sep 2009 22:36:15 -0700
Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
I wasn't really referring to the table used as a qualifier (in front
of the .). But in your sample statement, every /field/ name seemed to
contain the table name too...
traveler.travelerFirstName
On Wed, Sep 23, 2009 at 10:49 AM, D'Arcy J.M. Cain da...@druid.net wrote:
Of course you can get around this by specifying every field and using
AS to change the names to manager_id and employee_firstname, etc. but
if you are going to do that anyway, why not just do it once in the
database
On Wed, 23 Sep 2009 11:37:07 -0700
Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
On Wed, 23 Sep 2009 10:49:51 -0400, D'Arcy J.M. Cain da...@druid.net
declaimed the following in gmane.comp.python.general:
from pg import DB # PyGreSQL
db = DB() # uses my default PostgeSQL database
res =
