'SomeOtherString' ]
> a.sort().reverse()
[ true, null, {}, 'SomeOtherString', 1, [] ]
and this:
> a = [{}, [], null, true, 1, '2']
[ {}, [], null, true, 1, '2' ]
> a.sort().reverse()
[ true, null, {}, '2', 1, [] ]
So we can't replicate javascript sort order without emulating those.
Regards,
Ali Akbar
0
===
The client cannot reconnect. The service is dead. This is nasty, because
any client can exploit some segfault bug like the one in perl Dmitry
mentoined upthread, and the postgresql service is down.
Note: killing the server process with pg_terminate_backend isn't causing
this behavior to happen. The client reconnects normally, and the service is
still running.
Regards,
Ali Akbar
2015-01-20 18:17 GMT+07:00 Ali Akbar the.ap...@gmail.com:
2015-01-20 14:22 GMT+07:00 Jeff Davis pg...@j-davis.com:
The current patch, which I am evaluating for commit, does away with
per-group memory contexts (it uses a common context for all groups), and
reduces the initial array allocation
.
+ *
* astate is working state (must not be NULL)
* rcontext is where to construct result
*/
Regards,
--
Ali Akbar
2015-01-18 10:44 GMT+07:00 Peter Eisentraut pete...@gmx.net:
On 1/7/15 8:51 PM, Ali Akbar wrote:
So now +1 for back-patching this.
Done. Was a bit of work to get it into all the old versions.
Wow. Thanks.
Btw, for bug-fix patches like this, should the patch creator (me) also
create
the doc changes in a patch. Will add to next commitfest so it
won't be lost.
--
Ali Akbar
*** a/doc/src/sgml/xfunc.sgml
--- b/doc/src/sgml/xfunc.sgml
***
*** 2986,2991 SRF_RETURN_DONE(funcctx)
--- 2986,3005
structfieldmulti_call_memory_ctx/ while doing the first-call
above), i'll mark this
as ready for committer
Regards,
--
Ali Akbar
patch from Tomas only change initArrayResult* functions. initArrayResult
is new API in 9.5 (commit bac2739), with old API still works as-is.
--
Ali Akbar
context once for all.
Regards,
--
Ali Akbar
2014-12-16 11:01 GMT+07:00 Ali Akbar the.ap...@gmail.com:
2014-12-16 10:47 GMT+07:00 Ali Akbar the.ap...@gmail.com:
2014-12-16 6:27 GMT+07:00 Tomas Vondra t...@fuzzy.cz:
Just fast-viewing the patch.
The patch is not implementing the checking for not creating new context
this.
Just fast-viewing the patch.
The patch is not implementing the checking for not creating new context in
initArrayResultArr. I think we should implement it also there for
consistency (and preventing future problems).
Regards,
--
Ali Akbar
2014-12-16 10:47 GMT+07:00 Ali Akbar the.ap...@gmail.com:
2014-12-16 6:27 GMT+07:00 Tomas Vondra t...@fuzzy.cz:
On 15.12.2014 22:35, Jeff Janes wrote:
On Sat, Nov 29, 2014 at 8:57 AM, Tomas Vondra t...@fuzzy.cz
mailto:t...@fuzzy.cz wrote:
Hi,
Attached is v2 of the patch
the xml to table u 100 times. Load script attached.
Regards,
--
Ali Akbar
load_test.sql
Description: application/sql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2014-12-14 22:18 GMT+07:00 Ali Akbar the.ap...@gmail.com:
I ran a test using postgres-US.fo built in the PostgreSQL source tree,
which is 38 MB, and ran
select unnest(xpath('//fo:bookmark-title', b, array[array['fo',
'http://www.w3.org/1999/XSL/Format']])) from data;
(Table contains one
2014-12-15 10:19 GMT+07:00 Michael Paquier michael.paqu...@gmail.com:
On Mon, Dec 15, 2014 at 9:05 AM, Ali Akbar the.ap...@gmail.com wrote:
Peter, while reviewing the better performing patch myself, now i think
the
patch needs more work to be committed. The structuring of the method
2014-12-15 11:02 GMT+07:00 Ali Akbar the.ap...@gmail.com:
2014-12-15 10:19 GMT+07:00 Michael Paquier michael.paqu...@gmail.com:
On Mon, Dec 15, 2014 at 9:05 AM, Ali Akbar the.ap...@gmail.com wrote:
Peter, while reviewing the better performing patch myself, now i think
the
patch needs more
2014-12-15 11:06 GMT+07:00 Michael Paquier michael.paqu...@gmail.com:
On Mon, Dec 15, 2014 at 1:02 PM, Ali Akbar the.ap...@gmail.com wrote:
2014-12-15 10:19 GMT+07:00 Michael Paquier michael.paqu...@gmail.com:
On Mon, Dec 15, 2014 at 9:05 AM, Ali Akbar the.ap...@gmail.com wrote:
Peter
part However, if you want to allocate any data structures to
live across calls, you need to put them somewhere else. is buried in the
docs.
But i think explicit warning is more noticeable for new developer like me.
Regards,
--
Ali Akbar
2014-11-26 0:38 GMT+07:00 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2014-10-27 11:20 GMT+01:00 Ali Akbar the.ap...@gmail.com:
[ array_agg_anyarray-13.patch ]
This patch is ready for commit
I've committed this after some significant modifications.
I did
2014-11-04 22:16 GMT+07:00 Peter Eisentraut pete...@gmx.net:
On 10/6/14 10:24 PM, Ali Akbar wrote:
While reviewing the patch myself, i spotted some formatting problems in
the code. Fixed in this v5 patch.
Also, this patch uses context patch format (in first versions, because
2014-10-27 9:11 GMT+07:00 Ali Akbar the.ap...@gmail.com:
2014-10-27 1:38 GMT+07:00 Pavel Stehule pavel.steh...@gmail.com:
Hi
My idea is using new ArrayBuilder optimized for building multidimensional
arrays with own State type. I think so casting to ArrayBuildState is base
of our problems
minor changes in the patch:
* remove array_agg_finalfn_internal declaration in top of array_userfuncs.c
* fix comment of makeMdArray
* fix return of makeMdArray
* remove unnecesary changes to array_agg_finalfn
Regards,
--
Ali Akbar
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index
.
This patch is ready for commit
Thank you for patch
Thank you for the thorough review process.
Regards,
--
Ali Akbar
,
little bit more complex code is in nodeSubplan.c. Some schematic changes
are in attachments.
Thanks! The structure looks clear, and thanks for the example on
nodeSubplan.c. I will restructure the v10 of the patch to this structure.
Regards,
--
Ali Akbar
2014-10-25 10:29 GMT+07:00 Ali Akbar the.ap...@gmail.com:
I fixed small issue in regress tests and I enhanced tests for varlena
types and null values.
Thanks.
it is about 15% faster than original implementation.
15% faster than array_agg(scalar)? I haven't verify the performance
in array_agg, i think the
most natural way is using accumArrayResult and then makeArrayResult.
CMIIW
Regards,
--
Ali Akbar
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7e5bcd9..f59738a 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -12046,6 +12046,22 @@ NULL
2014-10-25 15:43 GMT+07:00 Pavel Stehule pavel.steh...@gmail.com:
2014-10-25 10:16 GMT+02:00 Ali Akbar the.ap...@gmail.com:
makeArrayResult1 - I have no better name now
I found one next minor detail.
you reuse a array_agg_transfn function. Inside is a message
array_agg_transfn called
varlena element - text). I tried several times and
it's consistent in +/- 30%.
quick dirty non-optimized patch and the test script attached.
Regards,
--
Ali Akbar
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7e5bcd9..f59738a 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src
for
shorted scalars - you should to expect so any array will be much larger.
this patch allocates 1KB (1024 bytes) if the ndatabytes is 512bytes. If
it is larger, it allocates 4 * size. For nullbitmap, it allocates 4 *
number of items in array.
Regards,
--
Ali Akbar
*** a/doc/src/sgml/func.sgml
attached.
Regards,
--
Ali Akbar
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
***
*** 12046,12051 NULL baz/literallayout(3 rows)/entry
--- 12046,12067
row
entry
indexterm
+ primaryarray_agg/primary
+/indexterm
, correct patch attached.
This patch is in patience format (git --patience ..). In previous patches,
i use context format (git --patience ... | filterdiff --format=context),
but it turns out that some modification is lost.
--
Ali Akbar
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
in accumArrayResult (arrayfuncs.c):
astate-alen = 64; /* arbitrary starting array size */
it can be any number not too small and too big. Too small, and we will
realloc shortly. Too big, we will end up wasting memory.
Regards,
--
Ali Akbar
2014-10-22 22:48 GMT+07:00 Pavel Stehule pavel.steh...@gmail.com:
2014-10-22 16:58 GMT+02:00 Ali Akbar the.ap...@gmail.com:
Thanks for the review
2014-10-22 20:51 GMT+07:00 Pavel Stehule pavel.steh...@gmail.com:
I agree with your proposal. I have a few comments to design:
1. patch
determine the dimension of the result?
is it 0? Or the result will be just an empty array {} ?
This updated patch rejects NULL and {} arrays as noted above.
Regards,
--
Ali Akbar
*** a/src/backend/utils/adt/array_userfuncs.c
--- b/src/backend/utils/adt/array_userfuncs.c
***
*** 16,21
/MAC_address,
that there is three numbering namespace for MAC: MAC-48, EUI-48 and EUI-64.
The last one is 64 bits long (8 bytes). Currently PostgreSQL's macaddr is
only 6 bytes long. Should we change it to 8 bytes (not in this patch, of
course)?
Regards,
--
Ali Akbar
something you're not supposed to do you still have the protection of all
other asserts)
- Less verbose than IF THEN RAISE END IF
+1
--
Ali Akbar
select array_agg(a) from (values(null::int[])) a(a);
1: array_agg(typeid = 1007, len = -1, typmod = -1, byval = f)
ERROR: cannot aggregate null arrays
Regards,
--
Ali Akbar
*** a/src/backend/utils/adt/array_userfuncs.c
--- b/src/backend/utils/adt/array_userfuncs.c
self oid?
Regards,
--
Ali Akbar
diff --git a/src/include/catalog/pg_type.h b/src/include/catalog/pg_type.h
index b7d9256..7934874 100644
--- a/src/include/catalog/pg_type.h
+++ b/src/include/catalog/pg_type.h
@@ -357,8 +357,8 @@ DATA(insert OID = 114 ( json PGNSP PGUID -1 f b U f t \054 0 0 199
and returns the correct rows:
numeric
-
-9
-8
-7
-6
-5
-4
-3
-2
-1
0
1
2
3
4
5
6
7
8
9
(19 rows)
Regards,
--
Ali Akbar
*** a/doc/src/sgml/func.sgml
--- b/doc/src
.
In this situation, what should i do?
Thanks for the review Manti!
Regards,
--
Ali Akbar
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
***
*** 14074,14081 AND
tbody
row
entryliteralfunctiongenerate_series(parameterstart/parameter, parameterstop/parameter
)
...
+ if (NUMERIC_IS_NAN(start_num) ||
NUMERIC_IS_NAN(finish_num))
...
+ if (PG_NARGS() == 3)
...
+ if (NUMERIC_IS_NAN(step_num))
Ah, didn't see it. Thanks. Fixed in this patch.
Regards,
--
Ali Akbar
*** a/doc/src/sgml/func.sgml
--- b/doc/src
as before
(because reimplement some of xmlNodeCopy code must be reimplemented here).
Reviewing the patch myself, i've found some code formatting problems. Will
fix and post in the patch's thread.
Regards,
--
Ali Akbar
anymore)
Thanks,
Ali Akbar
*** a/src/backend/utils/adt/xml.c
--- b/src/backend/utils/adt/xml.c
***
*** 141,149 static bool print_xml_decl(StringInfo buf, const xmlChar *version,
pg_enc encoding, int standalone);
static xmlDocPtr xml_parse(text *data, XmlOptionType xmloption_arg
digits after the decimal point. How can we check if the next step
overflows? As a comparison, in int.c, generate_series_step_int4 checks if
its overflows, and stop the next call by setting step to 0. Should we do
that?
~ will try to fix the patch later
--
Ali Akbar
2014-10-05 15:21 GMT+07:00 Ali Akbar the.ap...@gmail.com:
Hi
Oops, it seems that I have been too hasty here. With a fresh mind I looked
at my own patch again and found two bugs:
- Incorrect calculation of each step's value, making stuff crash, it is
necessary to switch to the context
Also, Платон Малюгин, can you add this patch to postgresql commitfest (
http://commitfest.postgresql.org)?
--
Ali Akbar
, which I omit here for
simplicity).
The patch works, albeit must be applied with --ignore-whitespace. Attached
the patch + xml_1.out updates.
I'm marking this ready for commit
--
Ali Akbar
diff --git a/src/backend/utils/adt/xml.c b/src/backend/utils/adt/xml.c
index 422be69..7abe215 100644
node could be dumped again in next xpath result).
Thanks,
Ali Akbar
2014-07-11 15:36 GMT+07:00 Ali Akbar the.ap...@gmail.com:
Greetings,
Attached modified patch to handle xmlCopyNode returning NULL. The patch is
larger because xmlerrcxt must be passed to xml_xmlnodetoxmltype (xmlerrcxt
check the return of xmlStaticCopyNode whether it's NULL. So if someday the
recursion returns NULL (maybe because of memory exhaustion), it will
SEGFAULT.
Knowing this but in libxml2 code, is this patch is still acceptable?
Thanks,
Ali Akbar
*** a/src/backend/utils/adt/xml.c
--- b/src/backend/utils
other cases
beside out-of-memory. Will update the patch according to these cases.
Thanks for the review.
--
Ali Akbar
).
I'm marking this ready for committer.
Thanks for the review. Hope i will be able to contribute a little here and
there in the future.
--
Ali Akbar
more easier to just use
crosstab. For storing it efficiently, the result can be transformed
into array manually.
PS: as Michael Paquier said above, its better if you could send the
patch in the .patch file format (see:
https://wiki.postgresql.org/wiki/Working_with_GIT).
--
Ali Akbar
--
Sent
() behavior, we
will only apply this to future versions. The old behavior is wrong
(according to XPath standard) for not including namespaces, but maybe there
are some application that depends on the old behavior.
Thanks!
--
Ali Akbar
and memory/storage benefit you
mentioned will be true. But if the values are sparse, there will be
many 0's, how it will perform?
I'm interested to benchmark it with some use cases, to confirm the
performance benefits of it.
--
Ali Akbar
--
Sent via pgsql-hackers mailing list (pgsql-hackers
). When the copy dumped, the resulting XML is complete with its
namespaces. Calling xmlCopyNode will need additional memory to execute, but
reimplementing its routine to handle namespace definition will introduce
much complexity to the code.
Note: This is my very first postgresql patch.
--
Ali
55 matches
Mail list logo
