Re: Proposal: access control jails (and introduction as aspiring GSoC student)

On Fri, Mar 26, 2010 at 12:07 PM, Robert Haas <robertmhaas(at)gmail(dot)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.