Re: Plans for 2.8
От | Federico Di Gregorio |
---|---|
Тема | Re: Plans for 2.8 |
Дата | |
Msg-id | 5d8d99e5-f028-3b69-139b-d09c185e7422@dndg.it обсуждение исходный текст |
Ответ на | Re: Plans for 2.8 (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Список | psycopg |
On 10/04/2018 04:05 PM, Daniele Varrazzo wrote: > On Thu, Oct 4, 2018 at 2:27 PM Federico Di Gregorio<fog@dndg.it> wrote: >> On 10/04/2018 02:38 PM, Daniele Varrazzo wrote: >>> A tiny improvement to SQL generation is already ready^W merged in >>> #732: it will be possible to use `Identifier("schema", "name")` which >>> would be rendered in dotted notation in the query. Currently >>> `Identifier()` takes a single param so this extension is backward >>> compatible and there is no need to introduce a new `Composable` type >>> to represent dotted sequences of identifiers. >> I understand that from a compatibility point of view everything works >> with the "schema", "name" order of arguments (you just switch on the >> number of arguments) but usually such approach causes infinite headaches >> when you remove or add the namespace from the call. >> >> `Identifier(name, schema=None)` is better, IMHO because makes explicit >> that the mandatory and first argument is always the identifier itself, >> while the schema is optional. > "schema", "table" is only an example: it could be "table"."field", > even "schema"."table"."field", or "extension"."setting"... The object > only wants to represent a dotted sequence of identifiers, at lexical > level, nothing with semantics attached such as "an optionally > schema-qualified table name" or "a field name". If the object was > `Table()` or `Field()` rather than `Identifier()` I'd totally agree > with you. Sorry, I misread your example. Obviously you're right. federico p.s. yep, I'll remove all the old cruft from sandbox. -- Federico Di Gregorio federico.digregorio@dndg.it DNDG srl http://dndg.it The number of the beast: vi vi vi. -- Delexa Jones
В списке psycopg по дате отправления: