I've been having an off-list discussion with Neil Conway about the
handling of lists in the backend's nodeToString and stringToNode
routines (outfuncs.c and readfuncs.c). Currently, the same string
representation
(1 2 3 4)
is used for a List of integer-flavor Value nodes, a List of integers,
and a list of OIDs. This means that readfuncs.c has to rely on
context knowledge to determine when it expects to read an integer list
or OID list. (If you look at the implementation, nodeRead() will always
return a Value list given this input, and then readfuncs.c has to change
the representation to be what it wants.)
This all seems pretty messy and inefficient; certainly it violates a
standard principle of data representation, which is "don't discard
information". I'm thinking that life would be better if we altered the
string representation so that integer and OID lists would be visibly
different from lists of Values. The first thought that comes to mind
is to insert "i" or "o" just after the left parenthesis:
(i 1 2 3 4) integer list
(o 1 2 3 4) OID list
(1 2 3 4) list of integer Values
({node} {node}) list of more complex Node types
Making this change would force an initdb due to change of stored rules,
which seems like no problem at this stage of the release cycle. It
would also cause a change in the output emitted by EXPLAIN VERBOSE ---
although we could choose to suppress the "i" or "o" in "pretty printed"
plan dumps so as not to break any existing clients that look at the
data. (Are there any?)
Any comments, objections, better ideas out there? Which way do people
want to jump on changing EXPLAIN VERBOSE format or not?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
