Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless) |
Дата | |
Msg-id | 21888.1487804399@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless) (Corey Huinker <corey.huinker@gmail.com>) |
Ответы |
Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless) |
Список | pgsql-hackers |
Corey Huinker <corey.huinker@gmail.com> writes: > After some research, GetVariable is called by psql_get_variable, which is > one of the callback functions passed to psql_scan_create(). So passing a > state variable around probably isn't going to work and PsqlFileState now > looks like the best option. Ah, I see why *that* wants to know about it ... I think. I suppose you're arguing that variable expansion shouldn't be able to insert, say, an \else in a non-active branch? Maybe, but if it can insert an \else in an active branch, then why not non-active too? Seems a bit inconsistent. Anyway, what this seems to point up is that maybe we should've allowed for a passthrough "void *" argument to the psqlscan callback functions. There wasn't one in the original design but it's a fairly standard part of our usual approach to callback functions, so it's hard to see an objection to adding one now. regards, tom lane
В списке pgsql-hackers по дате отправления: