From: | Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: access control jails (and introduction as aspiring GSoC student) |
Date: | 2010-03-27 02:19:14 |
Message-ID: | e7e5fefd1003261919qb7ddd5ch5b4e6f22fa40a69@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Gokulakannan Somasundaram | 2010-03-27 07:11:32 | Proposal for Performance improvement for unique checks |
Previous Message | Tom Lane | 2010-03-26 22:10:38 | Re: join removal |