Thanks for reviewing my patch!
On Mon, Jul 4, 2011 at 7:10 AM, Bernd Helmle maili...@oopsware.de wrote:
+comment = 'data type for storing and manipulating JSON content'
I'm not sure, if manipulating is a correct description. Maybe i missed it,
but i didn't see functions to manipulate JSON
On Fri, Jun 17, 2011 at 2:29 AM, Bernd Helmle maili...@oopsware.de wrote:
Joseph, are you able to remove the compatibility code for this CF?
Done. Note that this module builds, tests, and installs successfully
with USE_PGXS=1. However, building without USE_PGXS=1 produces the
following:
On Wed, May 11, 2011 at 7:53 AM, Robert Haas robertmh...@gmail.com wrote:
That's likely to be how it gets implemented, but you seem to have
missed the point of some of the discussion upthread: the big problem
with that is that someone might type DROP TYPE foo, and when they
do, you need an
It seems to me a reasonable way to implement VARIANT would be to have
a data type called VARIANT that stores an OID of the inner type at the
beginning, followed by the binary data. When you say
pg_typeof(somevariant), you'll get 'variant'. Instead, you'd use a
function like this:
On Tue, May 10, 2011 at 10:29 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
The VARIANT type, or similar, would be useful for the JSON data type
I've been intermittently working on, as it would allow us to create a
function like this:
from_json(JSON) returns VARIANT
This occurred
On Sun, Apr 3, 2011 at 11:23 PM, Robert Haas robertmh...@gmail.com wrote:
Thanks for the patch, but I think you forgot to worry about overflow:
rhaas=# select 9223372036854775807::money;
money
-$1.00
(1 row)
cash_in doesn't test for overflow, either (tested on 8.4.0, 9.0.3, and
Attached is an updated version of the patch to allow conversion of
int4/int8 directly to money. I added overflow checks, dropped
int2-cash, and updated the documentation.
- Joey
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index ecc79e2..13b888d 100644
---
2011/4/2 Devrim GÜNDÜZ dev...@gunduz.org:
I'm getting the following message after upgrading to Alpha5 on my Fedora
14 box:
$ psql -p 5433
psql: connection pointer is NULL
which comes from libpq. Server is running, and I can connect it to via
9.0's psql.
This is a regular RPM build. Am I
On Thu, Mar 31, 2011 at 6:39 PM, Stephen Frost sfr...@snowman.net wrote:
Going just integer-money, with the 1 - $1.00, seems completely
reasonable to me. As for being too late in the cycle.. if someone's
willing to do the work, I can't imagine it breaking anything, so I
wouldn't be against
On Tue, Mar 29, 2011 at 2:42 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Also, should uninstall_json.sql be named something else, like
json--uninstall--0.1.sql ?
You don't need no uninstall script no more, try DROP EXTENSION json; and
DROP EXTENSION json CASCADE;
It's there for
On Tue, Mar 29, 2011 at 2:42 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Joseph Adams joeyadams3.14...@gmail.com writes:
It would be nice if I could make a Makefile conditional that skips the
relocatable test and loads init-pre9.1.sql if the new extension
interface isn't available
On Tue, Mar 29, 2011 at 4:02 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Here's the ugly trick from ip4r, that's used by more extension:
PREFIX_PGVER = $(shell echo $(VERSION) | awk -F. '{ print $$1*100+$$2 }')
Thanks. I applied a minor variation of this trick to the JSON module,
so
On Mon, Mar 28, 2011 at 1:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 28, 2011 at 1:21 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
Attached is a patch that adds a 'json' contrib module. Although we
may want a built-in JSON data type in the near future, making
I discovered today that hstore's Makefile currently does not support
PGXS; namely, the ability to install it like so:
USE_PGXS=1 make
sudo USE_PGXS=1 make install
Moreover, hstore is the *only* contrib module whose Makefile does not
contain PGXS.
The attached patch changes hstore's
On Thu, Jan 20, 2011 at 8:13 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Jan 21, 2011 at 09:11, Bruce Momjian br...@momjian.us wrote:
What happened to our work to add a JSON data type for PG 9.1?
Nothing will happen in 9.1.
I assume we are in competition status:
On Tue, Oct 19, 2010 at 11:22 AM, Terry Laurenzo t...@laurenzo.org wrote:
Perhaps we should enumerate the attributes of what would make a good binary
encoding?
Not sure if we're discussing the internal storage format or the binary
send/recv format, but in my humble opinion, some attributes of a
On Mon, Sep 20, 2010 at 12:38 AM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
Here's one thing I'm worried about: the bison/flex code in your patch
looks rather similar to the code in
http://www.jsonlint.com/bin/jsonval.tgz , which is licensed under the
GPL. In particular, the incorrect
On Mon, Oct 4, 2010 at 7:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. Joseph seems to be confusing copyrights with patents. The idea
of parse JSON with bison/flex is not patentable by any stretch of the
imagination.
What I meant is, anyone who sets out to write a JSON parser with
On Sat, Sep 18, 2010 at 4:03 PM, Robert Haas robertmh...@gmail.com wrote:
Hmm, yeah. I'd be tempted to try to keep the user's original
whitespace as far as possible, but disregard it as far as equality
comparison goes. However, I'm not quite sure what the right thing to
do about 0 vs 0.0 is.
On Fri, Sep 17, 2010 at 8:32 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Fri, Aug 13, 2010 at 7:33 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
Updated patch: the JSON code has all been moved into core, so this
patch is now for a built-in data type.
I have a question
On Mon, Aug 23, 2010 at 1:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On Mon, August 23, 2010 11:49 am, Alvaro Herrera wrote:
What do you need AFTER for? Seems to me that BEFORE should be enough.
(You already have the unadorned syntax for adding an
On Sun, Aug 15, 2010 at 11:47 PM, Andrew Dunstan and...@dunslane.net wrote:
If BSON is simply in effect an efficient encoding of JSON, then it's not
clear to me that we would want another type at all. Rather, we might want to
consider storing the data in this supposedly more efficient format,
On Mon, Aug 16, 2010 at 7:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if it's not just a binary encoding of JSON, I think we can forget
about it ... certainly it won't work in the form I was visualizing.
regards, tom lane
I just read the spec, and BSON has a lot of
On Tue, Jul 27, 2010 at 1:31 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jul 24, 2010 at 10:34 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
In src/include/mb/pg_wchar.h , there is a function unicode_to_utf8 ,
but no corresponding utf8_to_unicode . However, there is a static
I factored out the general-purpose utility functions in the JSON data
type code into a patch against HEAD. I have made a few changes to
them since I posted about them earlier (
http://archives.postgresql.org/pgsql-hackers/2010-08/msg00692.php ).
A summary of the utility functions along with some
On Fri, Aug 13, 2010 at 10:46 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Aug 13, 2010 at 5:45 AM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
getEnumLabelOids
* Useful-ometer: ()---o
* Rationale: There is currently no streamlined way to return
On Fri, Aug 13, 2010 at 2:02 PM, David Fetter da...@fetter.org wrote:
On Fri, Aug 13, 2010 at 01:33:06PM -0400, Robert Haas wrote:
Maybe so, but it's not clear the interface that Joseph implemented is
the one everyone wants...
Fair enough. What's the interface now in a nutshell? Lack of
Update: I'm in the middle of cleaning up the JSON code (
http://git.postgresql.org/gitweb?p=json-datatype.git;a=summary if you
want to see the very latest ), so I haven't addressed all of the major
problems with it yet.
On Fri, Jul 23, 2010 at 2:34 PM, Robert Haas robertmh...@gmail.com wrote:
-
In src/include/mb/pg_wchar.h , there is a function unicode_to_utf8 ,
but no corresponding utf8_to_unicode . However, there is a static
function called utf2ucs that does what utf8_to_unicode would do.
I'd like this function to be available because the JSON code needs to
convert UTF-8 to and from
On Fri, Jun 18, 2010 at 1:59 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan and...@dunslane.net
wrote:
You are just bumping up the storage cost. Part of the attraction of enums
is
their efficiency.
What's efficient
Currently, the JSON datatype (repository:
http://git.postgresql.org/gitweb?p=json-datatype.git;a=summary ) is
implemented somewhat like a specialization of TEXT, like XML is. I'm
beginning to question if this is the right way to go. This doesn't
concern whether the JSON datatype should retain
On Fri, Jun 11, 2010 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
How about no operator at all? It won't be as cool to read, but
consider, the arguments are text and text, not involving any hstore type
at all, so whatever operator you choose is in
On Fri, May 28, 2010 at 9:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, May 28, 2010 at 12:07 AM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
I learned that to return an enum value from C, one needs to return the
OID of the right row
On Wed, May 26, 2010 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we go with the spec's syntax I think we'd have no realistic choice
except to forbid = altogether as an operator
On Fri, Jun 4, 2010 at 9:55 PM, Joseph Adams joeyadams3.14...@gmail.com wrote:
If I had to choose between = and := for parameter naming, I'd go with
:= because it seems more SQLish to me.
On second thought, = might actually be a very intuitive syntax for
defining dictionary types like hstore
I've started implementing the JSON datatype; the repo is at
http://git.postgresql.org/gitweb?p=json-datatype.git .
On Fri, May 14, 2010 at 1:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 13, 2010 at 9:47 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
Would it be a bad idea
I encountered a situation while implementing JSON support where I
needed to return an enum value from a C function. To clarify, here's
the SQL:
CREATE TYPE json_type_t AS ENUM ('null', 'string', 'number', 'bool',
'object', 'array');
CREATE OR REPLACE FUNCTION json_type(json)
RETURNS json_type_t
I started a wiki article for brainstorming the JSON API:
http://wiki.postgresql.org/wiki/JSON_API_Brainstorm . I also made
substantial changes to the draft of the API based on discussion here
and on the #postgresql IRC channel.
Is it alright to use the wiki for brainstorming, or should it stay
Well, I think it's fine to use the wiki for brainstorming, but before
you change the design you probably need to talk about it here. You
can't rely on everyone on -hackers to follow changes on a wiki page
somewhere. It looks like the API has been overhauled pretty heavily
since the last
On Tue, May 25, 2010 at 3:39 PM, Hector Beyers hqbey...@gmail.com wrote:
Hi guys,
(I tried the question in another forum first)
Does someone have any ideas how I can hide data without the meta data
noticing? To explain further, I would like to save some collection of data
where the meta-data
On Fri, May 14, 2010 at 11:33 AM, Bruce Momjian br...@momjian.us wrote:
Joseph Adams wrote:
== array/object conversion ==
The json_object function converts a tuple to a JSON object. If there
are duplicate column names, there will be duplicate keys in the
resulting JSON object.
json_object
First off, thank you for allowing me to participate in Google Summer
of Code 2010. I'm sorry I haven't been active for the past few weeks.
Today, I added the wiki page for my project, but the project schedule
is highly tentative:
http://wiki.postgresql.org/wiki/JSON_datatype_GSoC_2010 .
I'd
This isn't exactly a bug, but it could be considered unintuitive
behavior. Consider this:
CREATE VIEW foo AS SELECT * FROM a;
CREATE VIEW foo_v AS SELECT * FROM foo;
ALTER TABLE foo ADD COLUMN b INT;
The ALTER TABLE statement affects VIEW foo, but the column addition
does not propagate to VIEW
On Sat, Apr 10, 2010 at 10:00 AM, Jean-Gérard Pailloncy j...@rilk.com wrote:
Hello,
1) VPD: Virtual Private Database
I would appreciate to have a new feature in PostgreSQL.
This is an oracle-like feature that implement Row Level Security.
This feature may be emulated by using VIEW/RULE but
On Fri, Apr 9, 2010 at 5:02 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Necati Batur escribió:
*Delivarables on Timeline*
...
*Implementation of a GUI for XQuery for the PostgreSql users (2 week)
What, you will *also* implement a GUI? Gimme a break. There's no way
you can achieve
On Fri, Apr 9, 2010 at 4:08 PM, Dimitri Fontaine dfonta...@hi-media.com wrote:
I guess a GSoC of reasonable size would be to define a spec for how to
implement partitioning in PostgreSQL with a sound and accepted proposal
on independent steps to contribute separately, in order to reach the
On Tue, Apr 6, 2010 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Petr Jelinek pjmo...@pjmodos.net writes:
Dne 6.4.2010 7:57, Joseph Adams napsal(a):
To me, the most logical approach is to do the obvious thing: make
JSON's 'null' be SQL's NULL. For instance, SELECTing on a table with
NULLs
Another JSON strictness issue: the JSON standard (
http://www.ietf.org/rfc/rfc4627.txt ) states that JSON text can only
be an array or object. However, my implementation currently accepts
any valid value. Thus, '3', 'hello', 'true', 'false', and 'null'
are all accepted by my implementation, but
I've been wondering whether the JSON datatype should be strict or conservative.
For one, there's strict JSON (following the exact specification).
Then there's more conservative JSON variants. Some JSON parsers
support comments, some support invalid number formats (e.g. '3.' or
'+5'), etc..
The
I ended up reinventing the wheel and writing another JSON library:
http://constellationmedia.com/~funsite/static/json-0.0.1.tar.bz2
This is a first release, and it doesn't really have a name besides
json. It's very similar to cJSON, except it is (sans unknown bugs)
more reliable, more correct,
On Mon, Mar 29, 2010 at 2:23 PM, David E. Wheeler da...@kineticode.com wrote:
On Mar 29, 2010, at 9:02 AM, Tom Lane wrote:
If this is going to end up being one fairly small C file implementing
a spec that is not a moving target, I'd vote against depending on an
external library instead, no
I introduced myself in the thread Proposal: access control jails (and
introduction as aspiring GSoC student), and we discussed jails and
session-local variables. But, as Robert Haas suggested, implementing
variable support in the backend would probably be way too ambitious a
project for a newbie
On Sun, Mar 28, 2010 at 5:19 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
Now my thoughts and opinions on the JSON parsing/unparsing itself:
It should be built-in, rather than relying on an external library
(like
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
I apologize for my silence, as I've been busy reading up more on the
internals of PostgreSQL.
From what I can tell, a big problem with my jails idea (as well as the
variables Robert described) is that there really isn't a way to store
context in the backend specifically for the end client (e.g. a
Hello, I'm Joey Adams, and I'm interested in applying for Google
Summer of Code to work on PostgreSQL. I'm a former GSoC student (I
worked on CCAN last year), and a strong C programmer, though I am
still new to working with large, established communities. I apologize
if this is the wrong place
56 matches
Mail list logo