Re: GSOC13 proposal - extend RETURNING syntax
От | Karol Trzcionka |
---|---|
Тема | Re: GSOC13 proposal - extend RETURNING syntax |
Дата | |
Msg-id | 524E7F78.5020603@gmail.com обсуждение исходный текст |
Ответ на | Re: GSOC13 proposal - extend RETURNING syntax (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: GSOC13 proposal - extend RETURNING syntax
Re: GSOC13 proposal - extend RETURNING syntax |
Список | pgsql-hackers |
W dniu 04.10.2013 02:51, Robert Haas pisze: > Do you have a link to previous discussion on the mailing list? Sorry, most of discussion was at IRC channel. > I'm not positive there's enough information available > at that stage, but if p_target_rangetblentry is populated at that > point, you should be able to make AFTER.x translate to a Var > referencing that range table entry. It's not enough. Even if we know "where we are", there are more issues. The main question is: how should we pass information about "hello, I'm specific Var, don't evaluate me like others"? We can add two fields to Var structure (flag - normal/before/after and no. column) - however it needs to modify copyObject for Vars (at now it's done e.g. in flatten_join_alias_vars_mutator for varoattno and varnoold). If copyObject is modified, sure code in flatten_join_alias_vars_mutator/pullup_replace_vars_callback will be useless. I don't know if modifying pg at the low-level (changing structure of Var and behaviour of copyObject) is good idea. Yes if the community really want it but it needs more "votes". There is "medium" solution: changing Var structure and do the "copy" like now (in mutator and callback) but w/o the condition statement (for the new fields). I think it might need to modify more places in code because of "comparing" vars (maybe we'd need to include new fields while comparision). Regards, Karol Trzcionka
В списке pgsql-hackers по дате отправления: