Re: RealDictCursor behavior question
| От | Israel Brewster |
|---|---|
| Тема | Re: RealDictCursor behavior question |
| Дата | |
| Msg-id | 1CB636E7-B0CD-44FA-9508-F36EB8080188@flyravn.com обсуждение исходный текст |
| Ответ на | Re: RealDictCursor behavior question (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
| Ответы |
Re: RealDictCursor behavior question
(Christophe Pettus <xof@thebuild.com>)
Re: RealDictCursor behavior question (Karsten Hilbert <Karsten.Hilbert@gmx.net>) Re: RealDictCursor behavior question (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
| Список | psycopg |
On Apr 30, 2018, at 10:58 AM, Daniele Varrazzo <daniele.varrazzo@gmail.com> wrote:On Mon, Apr 30, 2018 at 7:18 PM, Israel Brewster <ibrewster@flyravn.com> wrote:When using the RealDictCursor from psycopg2 extras, is the behavior of RealDictCursor well defined for the case where you have repeated column names (such as in a join)? That is, obviously a dictionary can only have one value for a key, so is it safe to assume that the value for the column name key in the case of repeated column names is always going to be the one that appears LAST in the query?Not at all: the result is at best an error, at worse an undefined behaviour. Even if at the moment the result appears consistent we may change the implementation in the future.
Understood. Of course, that's why I asked.
Just out of curiosity though: why? The behavior of Postgresql with repeated column names is neither an error or undefined. The following query works fine, and produces well-defined results:
SELECT 'one' AS one, 'two' AS two, 'three' AS one;
No errors are given, and the columns are returned in the same order as given in the query. In fact, this behavior is required for the basic non-dict cursor to work, otherwise you wouldn't be able to reference by index.
The behavior of python dictionaries when presented with multiple values for the same key is also well-defined and not an error: the last value presented is the value it gets.
So, given that both the input and the output have well-defined, non-error behavior for the situation, why does the middle step - assigning the raw result from the query to a dictionary - become "at best an error, at worse an undefined behavior"?
PLEASE NOTE: I am not arguing about the implementation here, if it is good or bad. I'm just curious about the design choices that went into it, and why this behavior *isn't* well-defined, especially given the ease with which it could arise.
Do specify explicit names for the columns, and never use `select *` in production, which may result in accidental duplications (maybe not now, but in the future, when you add an apparently unrelated field to a table and grep can't help you).
Yes, that is good reasoning *in general*, however in my particular use case, using `select *` makes things so much cleaner as to be worth the -again, in my use case - quite small risk. At least, until now that was the case. :-)
-- Daniele
В списке psycopg по дате отправления: