On 02/05/2013 02:09 AM, Pavel Stehule wrote:
I don't see any nice on design select
myjson-'{authors,0,name}'::text[]; - more it is ugly as
dinosaurs
I rather like dinosaurs. Beauty is, as they say, in the eye of the beholder.
Let me also point out that you can say (somewhat less
2013/2/5 Andrew Dunstan and...@dunslane.net:
On 02/05/2013 02:09 AM, Pavel Stehule wrote:
I don't see any nice on design select
myjson-'{authors,0,name}'::text[]; - more it is ugly as
dinosaurs
I rather like dinosaurs. Beauty is, as they say, in the eye of the beholder.
Let me also
On Fri, Feb 1, 2013 at 4:08 PM, Robert Haas robertmh...@gmail.com wrote:
But even leaving that aside, I'm surprised to hear so many people
dismissing SQL standards compliance so blithely. We've certainly
spent a lot of blood, sweat, and tears on minor standards-compliance
issues over they
On Sun, Feb 3, 2013 at 9:05 PM, Andrew Dunstan and...@dunslane.net wrote:
Yeah, this is surely not a workable policy unless we first move all
those planner smarts to apply to functions not operators. And rewrite
all the index AM APIs to use functions not operators, too. Now this is
something
On 02/04/2013 10:47 AM, Robert Haas wrote:
The SQL standards considerations seem worth thinking about, too.
We've certainly gone through a lot of pain working toward eliminating
= as an operator name, and if the SQL standard has commandeered -
for some purpose or other, I'd really rather not
On Mon, Feb 4, 2013 at 4:10 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2013 10:47 AM, Robert Haas wrote:
The SQL standards considerations seem worth thinking about, too.
We've certainly gone through a lot of pain working toward eliminating
= as an operator name, and if the SQL
On Feb 4, 2013, at 8:10 AM, Andrew Dunstan and...@dunslane.net wrote:
My suggestion would be ~ and ~. I know David Wheeler didn't like that on
the ground that some fonts elevate ~ rather than aligning it in the middle as
most monospaced fonts do, but I'm tempted just to say then use a
On Mon, Feb 4, 2013 at 10:18 AM, Benedikt Grundmann
bgrundm...@janestreet.com wrote:
On Mon, Feb 4, 2013 at 4:10 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2013 10:47 AM, Robert Haas wrote:
The SQL standards considerations seem worth thinking about, too.
We've certainly gone
On 02/04/2013 12:57 PM, Merlin Moncure wrote:
*) it's bad enough that we drift from sql naming conventions and all
type manipulation functions (except in hstore) with type name.
json_get etc. at least using operators allow avoiding some of that
unnecessary verbosity. what's next:
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2013 10:47 AM, Robert Haas wrote:
The SQL standards considerations seem worth thinking about, too.
We've certainly gone through a lot of pain working toward eliminating
= as an operator name, and if the SQL
On Mon, Feb 4, 2013 at 12:07 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2013 12:57 PM, Merlin Moncure wrote:
*) it's bad enough that we drift from sql naming conventions and all
type manipulation functions (except in hstore) with type name.
json_get etc. at least using
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas robertmh...@gmail.com wrote:
I suspect both of those are pretty safe from an SQL standards point of
view. Of course, as Tom is often wont to point out, the SQL standards
committee sometimes does bizarre things, so nothing's perfect, but I'd
be
On 02/04/2013 02:59 PM, Merlin Moncure wrote:
On Mon, Feb 4, 2013 at 12:07 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2013 12:57 PM, Merlin Moncure wrote:
*) it's bad enough that we drift from sql naming conventions and all
type manipulation functions (except in hstore) with type
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2013 10:47 AM, Robert Haas wrote:
The SQL standards considerations seem worth thinking about, too.
We've certainly gone through a lot
On 02/04/2013 03:16 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2013 10:47 AM, Robert Haas wrote:
The SQL standards considerations seem worth thinking
On Mon, Feb 4, 2013 at 2:10 PM, Andrew Dunstan and...@dunslane.net wrote:
My only remaining nit with the proposal is with json_unnest().
SQL unnest() produces list of scalars regardless of dimensionality --
json unnest unwraps one level only (contrast: pl/pgsql array 'slice').
So I think
On Mon, Feb 4, 2013 at 12:37 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2013 03:16 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas robertmh...@gmail.com
wrote:
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan and...@dunslane.net
wrote:
On 02/04/2013 10:47
On 02/04/2013 04:19 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 12:37 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/04/2013 03:16 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas robertmh...@gmail.com
wrote:
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan
On 01/31/2013 11:20 PM, Andrew Dunstan wrote:
I'm happy to take opinions about this, and I expected
some bikeshedding, but your reaction is contrary to
everything others have told me. Mostly they love the operators.
What I would really like is if we extended postgresql core and made
a few more
2013/2/5 Hannu Krosing ha...@krosing.net:
On 01/31/2013 11:20 PM, Andrew Dunstan wrote:
I'm happy to take opinions about this, and I expected
some bikeshedding, but your reaction is contrary to
everything others have told me. Mostly they love the operators.
What I would really like is if
On Fri, Feb 1, 2013 at 6:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas robertmh...@gmail.com wrote:
I think it's smarter for us to ship functions, and let users wrap them
in operators if they so choose. It's not
On 02/03/2013 08:20 PM, Robert Haas wrote:
On Fri, Feb 1, 2013 at 6:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina dan...@heroku.com writes:
On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas robertmh...@gmail.com wrote:
I think it's smarter for us to ship functions, and let users wrap
On Thu, Jan 31, 2013 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
I would like to not create any - operators, so that that
On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 31, 2013 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2013 05:06 PM, Peter
Daniel Farina dan...@heroku.com writes:
On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas robertmh...@gmail.com wrote:
I think it's smarter for us to ship functions, and let users wrap them
in operators if they so choose. It's not difficult for people who
The problem being: even though pg_operator
On 1/10/13 6:42 PM, Andrew Dunstan wrote:
This updated patch contains all the intended functionality, including
operators for the json_get_path functions, so you can say things like
select jsonval-array['f1','0','f2] ...
I would like to not create any - operators, so that that syntax
On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
On 1/10/13 6:42 PM, Andrew Dunstan wrote:
This updated patch contains all the intended functionality, including
operators for the json_get_path functions, so you can say things like
select jsonval-array['f1','0','f2] ...
I would like to
On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
On 1/10/13 6:42 PM, Andrew Dunstan wrote:
This updated patch contains all the intended functionality, including
operators for the json_get_path functions, so you can
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
I would like to not create any - operators, so that that syntax could
be used in the future for method invocation or something
On Jan 31, 2013, at 2:20 PM, Andrew Dunstan and...@dunslane.net wrote:
I'm happy to take opinions about this, and I expected some bikeshedding, but
your reaction is contrary to everything others have told me. Mostly they love
the operators.
I guess that '~' and '~' would work as well as
On 01/31/2013 07:16 PM, David E. Wheeler wrote:
On Jan 31, 2013, at 2:20 PM, Andrew Dunstan and...@dunslane.net wrote:
I'm happy to take opinions about this, and I expected some bikeshedding, but
your reaction is contrary to everything others have told me. Mostly they love
the operators.
I
Andrew Dunstan and...@dunslane.net writes:
On 01/31/2013 07:16 PM, David E. Wheeler wrote:
I suppose that := is out of the question?
Even if it were I would not on any account use it. As an old Ada
programmer my mind just revolts at the idea of using this for anything
but assignment.
Ada
On Jan 31, 2013, at 4:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ada or no, its use in plpgsql would render that a seriously bad idea.
I assumed that its use in function params would be the main reason not to use
it.
David
--
Sent via pgsql-hackers mailing list
On 01/02/13 13:26, Andrew Dunstan wrote:
On 01/31/2013 07:16 PM, David E. Wheeler wrote:
On Jan 31, 2013, at 2:20 PM, Andrew Dunstan and...@dunslane.net wrote:
I'm happy to take opinions about this, and I expected some
bikeshedding, but your reaction is contrary to everything others
have
On Mon, Jan 14, 2013 at 11:02 PM, Andrew Dunstan and...@dunslane.net wrote:
After a couple of iterations, some performance enhancements to the json
parser and lexer have ended up with a net performance improvement over git
tip. On our test rig, the json parse test runs at just over 13s per
On Mon, Jan 14, 2013 at 07:52:56PM -0500, Andrew Dunstan wrote:
On 01/14/2013 07:36 PM, Merlin Moncure wrote:
While testing this I noticed that integer based 'get' routines are
zero based -- was this intentional? Virtually all other aspects of
SQL are 1 based:
postgres=# select
On Tue, Jan 15, 2013 at 1:04 PM, David Fetter da...@fetter.org wrote:
On Mon, Jan 14, 2013 at 07:52:56PM -0500, Andrew Dunstan wrote:
On 01/14/2013 07:36 PM, Merlin Moncure wrote:
While testing this I noticed that integer based 'get' routines are
zero based -- was this intentional? Virtually
On 01/15/2013 02:47 PM, Merlin Moncure wrote:
On Tue, Jan 15, 2013 at 1:04 PM, David Fetter da...@fetter.org wrote:
On Mon, Jan 14, 2013 at 07:52:56PM -0500, Andrew Dunstan wrote:
On 01/14/2013 07:36 PM, Merlin Moncure wrote:
While testing this I noticed that integer based 'get' routines are
On Tue, Jan 15, 2013 at 12:17 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/15/2013 02:47 PM, Merlin Moncure wrote:
On Tue, Jan 15, 2013 at 1:04 PM, David Fetter da...@fetter.org wrote:
On Mon, Jan 14, 2013 at 07:52:56PM -0500, Andrew Dunstan wrote:
On 01/14/2013 07:36 PM, Merlin
On Jan 15, 2013, at 12:17 PM, Andrew Dunstan and...@dunslane.net wrote:
I doubt I'm very representative either. People like David Wheeler, Taras
Mitran, Joe Van Dyk, and the Heroku guys would be better people to ask than
me. I'm quite prepared to change it if that's the consensus.
They’re
On 16/01/13 08:04, David Fetter wrote:
On Mon, Jan 14, 2013 at 07:52:56PM -0500, Andrew Dunstan wrote:
On 01/14/2013 07:36 PM, Merlin Moncure wrote:
While testing this I noticed that integer based 'get' routines are
zero based -- was this intentional? Virtually all other aspects of
SQL are 1
On Thu, Jan 10, 2013 at 6:42 PM, Andrew Dunstan and...@dunslane.net wrote:
Udated patch that contains most of the functionality I'm after. One piece
left is populate_recordset (populate a set of records from a single json
datum which is an array of objects, in one pass). That requires a bit of
On 01/14/2013 11:32 AM, Robert Haas wrote:
So, how much performance does this lose on json_in() on a large
cstring, as compared with master?
That's a good question. I'll try to devise a test.
I can't shake the feeling that this is adding a LOT of unnecessary
data copying. For one thing,
On Thu, Jan 10, 2013 at 5:42 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/04/2013 03:23 PM, Andrew Dunstan wrote:
On 01/02/2013 05:51 PM, Andrew Dunstan wrote:
On 01/02/2013 04:45 PM, Robert Haas wrote:
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan and...@dunslane.net
wrote:
On 01/14/2013 07:36 PM, Merlin Moncure wrote:
While testing this I noticed that integer based 'get' routines are
zero based -- was this intentional? Virtually all other aspects of
SQL are 1 based:
postgres=# select json_get('[1,2,3]', 1);
json_get
--
2
(1 row)
postgres=# select
On Mon, Jan 7, 2013 at 4:15 PM, Andrew Dunstan and...@dunslane.net wrote:
You (Merlin) have kindly volunteered to work on documentation, so before we
go too far with that any bikeshedding on names, or on the functionality
being provided, should now take place.
Barring comment/complaint, I'm
On 01/08/2013 01:45 AM, james wrote:
The processing functions have been extended to provide
populate_record() and populate_recordset() functions.The latter in
particular could be useful in decomposing a piece of json
representing an array of flat objects (a fairly common pattern) into
a set
I had been wondering how to do such an insertion efficiently in the context of
SPI, but it seems that there is no SPI_copy equiv that would allow a query
parse and plan to be avoided.
Your query above would need to be planned too, although the plan will be
trivial.
Ah yes, I meant that I
On 01/08/2013 09:58 AM, Andrew Dunstan wrote:
If you have such a datum, parsing it involves having it in memory and
then taking a copy (I wonder if we could avoid that step - will take a
look).
Here is a Proof Of Concept patch against my development tip on what's
involved in getting the
On 01/08/2013 03:12 PM, Andrew Dunstan wrote:
On 01/08/2013 09:58 AM, Andrew Dunstan wrote:
If you have such a datum, parsing it involves having it in memory and
then taking a copy (I wonder if we could avoid that step - will take
a look).
Here is a Proof Of Concept patch against my
On 01/08/2013 03:07 PM, james wrote:
Yes - but I don't think I can use COPY from a stored proc context can
I? If I could use binary COPY from a stored proc that has received a
binary param and unpacked to the data, it would be handy.
You can use COPY from a stored procedure, but only
On 1/7/13 5:15 PM, Andrew Dunstan wrote:
You (Merlin) have kindly volunteered to work on documentation, so before
we go too far with that any bikeshedding on names, or on the
functionality being provided, should now take place.
Hmm, I was going to say, this patch contains no documentation, so
You can use COPY from a stored procedure, but only to and from files.
I think that's in the chocolate fireguard realm though as far as
efficiency for this sort of scenario goes, even if its handled by
retaining an mmap'd file as workspace.
If SPI provided a way to perform a copy to a
On Tue, Jan 8, 2013 at 3:19 PM, Peter Eisentraut pete...@gmx.net wrote:
On 1/7/13 5:15 PM, Andrew Dunstan wrote:
You (Merlin) have kindly volunteered to work on documentation, so before
we go too far with that any bikeshedding on names, or on the
functionality being provided, should now take
On 01/08/2013 04:32 PM, Merlin Moncure wrote:
On Tue, Jan 8, 2013 at 3:19 PM, Peter Eisentrautpete...@gmx.net wrote:
On 1/7/13 5:15 PM, Andrew Dunstan wrote:
You (Merlin) have kindly volunteered to work on documentation, so before
we go too far with that any bikeshedding on names, or on the
On Fri, Jan 4, 2013 at 3:03 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I understand - but hstore isn't in core - so it should not be precedent
regexp_split_to_table
I am not native speaker, it sounds little bit strange - but maybe
because I am not native speaker :)
it's common usage:
2013/1/7 Merlin Moncure mmonc...@gmail.com:
On Fri, Jan 4, 2013 at 3:03 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I understand - but hstore isn't in core - so it should not be precedent
regexp_split_to_table
I am not native speaker, it sounds little bit strange - but maybe
because I
The processing functions have been extended to provide populate_record() and
populate_recordset() functions.The latter in particular could be useful in
decomposing a piece of json representing an array of flat objects (a fairly
common pattern) into a set of Postgres records in a single pass.
Hello
2013/1/4 Andrew Dunstan and...@dunslane.net:
On 01/02/2013 05:51 PM, Andrew Dunstan wrote:
On 01/02/2013 04:45 PM, Robert Haas wrote:
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan and...@dunslane.net
wrote:
Here is a patch for the first part of the JSON API that was recently
On 01/04/2013 03:36 PM, Pavel Stehule wrote:
Hello
2013/1/4 Andrew Dunstan and...@dunslane.net:
On 01/02/2013 05:51 PM, Andrew Dunstan wrote:
On 01/02/2013 04:45 PM, Robert Haas wrote:
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan and...@dunslane.net
wrote:
Here is a patch for the
2013/1/4 Andrew Dunstan and...@dunslane.net:
On 01/04/2013 03:36 PM, Pavel Stehule wrote:
Hello
2013/1/4 Andrew Dunstan and...@dunslane.net:
On 01/02/2013 05:51 PM, Andrew Dunstan wrote:
On 01/02/2013 04:45 PM, Robert Haas wrote:
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan and...@dunslane.net wrote:
Here is a patch for the first part of the JSON API that was recently
discussed. It includes the json parser hook infrastructure and functions
for json_get and friends, plus json_keys.
As is, this exposes the json
On 01/02/2013 04:45 PM, Robert Haas wrote:
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan and...@dunslane.net wrote:
Here is a patch for the first part of the JSON API that was recently
discussed. It includes the json parser hook infrastructure and functions
for json_get and friends, plus
63 matches
Mail list logo
