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

On Fri, Mar 26, 2010 at 10:19 PM, Joseph Adams
<joeyadams3(dot)14159(at)gmail(dot)com> wrote:
> 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.

That could work, though I'm not totally sure I like the design.

>> 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".

Well, that's one of the central questions: is that the best approach,
or should we integrate to an external library and if so which one?
That's part of why this is a research problem.

> 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.

Yeah. And the row can always be toasted afterwards if appropriate.

...Robert