Re: [PATCHES] WITH DELIMITERS in COPY
От | Tom Lane |
---|---|
Тема | Re: [PATCHES] WITH DELIMITERS in COPY |
Дата | |
Msg-id | 1894.1019000057@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] WITH DELIMITERS in COPY (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [PATCHES] WITH DELIMITERS in COPY
|
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > The code that bothered me about the CREATE DATABASE param processing > was: > /* process additional options */ > foreach(l, $5) > { > List *optitem = (List *) lfirst(l); > switch (lfirsti(optitem)) > { > case 1: > n->dbpath = (char *) lsecond(optitem); > break; > case 2: > n->dbtemplate = (char *) lsecond(optitem); > break; > case 3: > n->encoding = lfirsti(lnext(optitem)); > break; > case 4: > n->dbowner = (char *) lsecond(optitem); > break; > } > } > I see what it is doing, but it seems quite unclear. Seeing that people > are using this as a pattern for other param processing, I will work on a > patch to convert this to DefElem. Oh, I think we were talking at cross-purposes then. What you're really unhappy about is that this uses a list of two-element sublists? Yeah, I agree, that's a messy data structure; a list of DefElem would be perhaps cleaner. Not sure if it matters all that much though, since the list only exists in the context of a few productions in gram.y. Perhaps adding a couple of lines of documentation would be better than changing the code. regards, tom lane
В списке pgsql-hackers по дате отправления: