2013/2/5 Andrew Dunstan :
>
> 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 al
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 ef
2013/2/5 Hannu Krosing :
> 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 ext
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
On 02/04/2013 04:19 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 12:37 PM, Andrew Dunstan wrote:
On 02/04/2013 03:16 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas
wrote:
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan
wrote:
On 02/04/2013 10:47 AM, Robert Haas w
On Mon, Feb 4, 2013 at 12:37 PM, Andrew Dunstan wrote:
>
> On 02/04/2013 03:16 PM, Daniel Farina wrote:
>>
>> On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas
>> wrote:
>>>
>>> On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan
>>> wrote:
On 02/04/2013 10:47 AM, Robert Haas wrote:
>
>
On Mon, Feb 4, 2013 at 2:10 PM, Andrew Dunstan 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 'json_arra
On 02/04/2013 03:16 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas wrote:
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan 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
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas wrote:
> On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan 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 eli
On 02/04/2013 02:59 PM, Merlin Moncure wrote:
On Mon, Feb 4, 2013 at 12:07 PM, Andrew Dunstan 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.
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas 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 rather shocked if an
On Mon, Feb 4, 2013 at 12:07 PM, Andrew Dunstan 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 operators allow avo
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan 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 standard
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: text_concat
On Mon, Feb 4, 2013 at 10:18 AM, Benedikt Grundmann
wrote:
>
>
>
> On Mon, Feb 4, 2013 at 4:10 PM, Andrew Dunstan 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
On Feb 4, 2013, at 8:10 AM, Andrew Dunstan 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 different
> font."
On Mon, Feb 4, 2013 at 4:10 PM, Andrew Dunstan 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 standard
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 Sun, Feb 3, 2013 at 9:05 PM, Andrew Dunstan 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 that's
On Fri, Feb 1, 2013 at 4:08 PM, Robert Haas 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 years - why is it OK
On 02/03/2013 08:20 PM, Robert Haas wrote:
On Fri, Feb 1, 2013 at 6:03 PM, Tom Lane wrote:
Daniel Farina writes:
On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas 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
On Fri, Feb 1, 2013 at 6:03 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas 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:
Daniel Farina writes:
> On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas 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 resolves to functions in
> pg_pr
On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas wrote:
> On Thu, Jan 31, 2013 at 7:12 PM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan wrote:
On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
> I would like to not create any -> operators, so t
On Thu, Jan 31, 2013 at 7:12 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan 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 metho
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 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 l
On Jan 31, 2013, at 4:32 PM, Tom Lane 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 (pgsql-hackers@postgresql.org)
To make changes
Andrew Dunstan 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 or no, its use
On 01/31/2013 07:16 PM, David E. Wheeler wrote:
On Jan 31, 2013, at 2: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.
I guess that '~>' and
On Jan 31, 2013, at 2: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.
>
> I guess that '~>' and '~>>' would work as well as '->' and '->>
Merlin Moncure writes:
> On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan 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 similar (it's
>>> in the SQL s
On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan 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 say thi
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 no
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 synta
On Mon, Jan 14, 2013 at 11:02 PM, Andrew Dunstan 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 1
> parses on git
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 b
On Jan 15, 2013, at 12:17 PM, Andrew Dunstan 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 JSON arrays, not S
On Tue, Jan 15, 2013 at 12:17 PM, Andrew Dunstan wrote:
>
> On 01/15/2013 02:47 PM, Merlin Moncure wrote:
>>
>> On Tue, Jan 15, 2013 at 1:04 PM, 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:
On 01/15/2013 02:47 PM, Merlin Moncure wrote:
On Tue, Jan 15, 2013 at 1:04 PM, 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 -- wa
On Tue, Jan 15, 2013 at 1:04 PM, 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 o
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=# selec
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 js
On Thu, Jan 10, 2013 at 5:42 PM, Andrew Dunstan 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
wrote:
>
>
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, i
On Thu, Jan 10, 2013 at 6:42 PM, Andrew Dunstan 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
>> thought.
>>
On Mon, Jan 7, 2013 at 4: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.
Barring comment/complaint, I'm just going to roll
On 01/08/2013 04:32 PM, Merlin Moncure wrote:
On Tue, Jan 8, 2013 at 3:19 PM, Peter Eisentraut 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 be
On Tue, Jan 8, 2013 at 3:19 PM, Peter Eisentraut 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 place.
>
>
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 temp
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, s
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 to
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 deve
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 J
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 h
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 o
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.
2013/1/7 Merlin Moncure :
> On Fri, Jan 4, 2013 at 3:03 PM, Pavel Stehule 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 :)
>
>
On Fri, Jan 4, 2013 at 3:03 PM, Pavel Stehule 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: http://api.jquery
2013/1/4 Andrew Dunstan :
>
> On 01/04/2013 03:36 PM, Pavel Stehule wrote:
>>
>> Hello
>>
>>
>>
>> 2013/1/4 Andrew Dunstan :
>>>
>>> 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 01/04/2013 03:36 PM, Pavel Stehule wrote:
Hello
2013/1/4 Andrew Dunstan :
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
wrote:
Here is a patch for the first part of the JSON API that was recent
Hello
2013/1/4 Andrew Dunstan :
>
> 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
>>> wrote:
Here is a patch for the first part of the JSON API that was recently
discussed.
On 01/02/2013 04:45 PM, Robert Haas wrote:
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan 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, thi
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan 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 lexer fully for use
63 matches
Mail list logo
