On Tue, Sep 20, 2022 at 4:03 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Tue, Sep 20, 2022 at 3:58 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Thomas Munro <thomas.mu...@gmail.com> writes: > > > FWIW, it derives from Lisp s-expressions, but deviates from Lisp's > > > default reader/printer behaviour in small ways, including being case > > > sensitive and using {NAME :x 1 ...} instead of #S(NAME :x 1 ...) for > > > structs for reasons that are lost AFAIK (there's a dark age between > > > the commit history of the old Berkeley repo and our current repo, and > > > it looks like plan nodes were still printed as #(NAME ...) at > > > Berkeley). > > > > Wow, where did you find a commit history for Berkeley's code? > > There's evidence in the tarballs I have that they were using > > RCS, but I never heard that the repo was made public. > > One of the tarballs at https://dsf.berkeley.edu/postgres.html has the > complete RCS history, but Stas Kelvich imported it to github as Peter > G has just reported faster than I could.
To explain my earlier guess: reader code for #S(STRUCTNAME ...) can bee seen here, though it's being lexed as "PLAN_SYM" so perhaps the author of that C already didn't know that was a general syntax for Lisp structs. (Example: at a Lisp prompt, if you write (defstruct foo x y z) then (make-foo :x 1 :y 2 :z 3), the resulting object will be printed as #S(FOO :x 1 :y 2 :z 3), so I'm guessing that the POSTGRES Lisp code, which sadly (for me) was ripped out before even that repo IIUC, must have used defstruct-based plans.) https://github.com/kelvich/postgres_pre95/blob/master/src/backend/lib/lispread.c#L132 It may still be within the bounds of what a real Lisp could be convinced to read though, given a reader macro to handle {} and maybe some other little tweaks here and there.