On Fri, Mar 26, 2010 at 12:07 PM, Robert Haas <robertmh...@gmail.com> wrote:
> Hmm. I'm not sure exactly what problem you're trying to solve here. > I don't think this is a particularly good design for supporting > variables inside the server, since, well, it doesn't actually support > variables inside the server. If we just want a crude hack for > allowing the appearance of session-local server-side variables, that > could be implemented entirely in client code - in fact it could be > done as a thin wrapper around libpq that just does textual > substitution of the variables actually referenced by a particular > query. That wouldn't require any modifications to core PostgreSQL at > all, and it would probably perform better too since you'd not send all > the unnecessary variables with every query. One problem with a textual substitution is that implicit variable use (e.g. selecting from a view) can't be substituted, at least not trivially. As for "sending unnecessary variables with every query", my idea was to store those variables in a global table keyed by context ID, then just send that context ID with every query. > But, I think that implementing any kind of variable support in the > backend is way too ambitious a project for a first-time hacker to get > done in a couple of months. I would guess that's a two-year project > for a first time hacker or a one-year project for an experienced > hacker (or a three week project for Tom Lane). Here are some ideas > from http://wiki.postgresql.org/wiki/Todo that I think MIGHT be closer > to the right size for GSOC: > [...] > Add JSON (JavaScript Object Notation) data type [tricky part will be > getting community buy-in on which JSON library to use] The JSON idea caught my eye. I guess the best approach here would be not to use an external library, but to implement it manually using flex/bison. Most of the work would probably revolve around converting things to/from PostgreSQL types, writing test cases, and getting it integrated; writing the parser itself should be a "piece of cake". At first, I figured adding JSON support would be almost too trivial: just parse it, then you're done. After seeing that src/backend/utils/adt/xml.c is 3497 lines, I learned there's a bit more to it :) I skimmed through some JSON implementations in C, and I didn't find any using bison/flex. From the looks of it, I do like JSON_parser ( http://fara.cs.uni-potsdam.de/~jsg/json_parser/ ) because it appears to be written for speed. I think one benefit of adding JSON support is that it would provide a way to store EAV-type data with less overhead than XML (and no dependency on an external library). If this were the only goal, binary encoding would be even better. However, I suppose JSON is more popular and easier to work with in practice. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers