Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context

čt 28. 2. 2019 v 10:31 odesílatel Pavel Stehule napsal: > > > čt 28. 2. 2019 v 9:58 odesílatel Ramanarayana > napsal: > >> Hi, >> >> I have tested the three issues fixed in patch 001. Array Indexes >> issue is still there.Running the following quer

plpgsql variable named as SQL keyword

Hi one user of plpgsql_check reported interesting error message create or replace function omega.foo(a int) returns int as $$ declare offset integer := 0; begin return offset + 1; end; $$ language plpgsql; postgres=# select omega.foo(10); ERROR: query "SELECT offset + 1" returned 0 columns CO

Re: plpgsql variable named as SQL keyword

čt 28. 2. 2019 v 19:20 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > Maybe we should to disallow variables named as sql reserved keyword. > > That would just break existing code. There are lots of other > examples where you can get away with such things. > >

Re: jsonpath

so 2. 3. 2019 v 6:15 odesílatel Alexander Korotkov < a.korot...@postgrespro.ru> napsal: > Hi! > > On Fri, Mar 1, 2019 at 3:36 AM Nikita Glukhov > wrote: > > > > Attached 34th version of the patches. > > > > 1. Partial jsonpath support: > >- Fixed copying of jsonb with vars jsonb_path_query()

Re: [HACKERS] proposal: schema variables

Hi čt 31. 1. 2019 v 12:49 odesílatel Pavel Stehule napsal: > Hi > > just rebase > > regards > > Pavel > rebase and fix compilation due changes related pg_dump Regards Pavel schema-variables-20190303.patch.gz Description: application/gzip

Re: Re: proposal: new polymorphic types - commontype and commontypearray

út 5. 3. 2019 v 14:38 odesílatel David Steele napsal: > On 2/4/19 4:21 AM, Michael Paquier wrote: > > On Wed, Jan 30, 2019 at 05:08:03PM +0100, Pavel Stehule wrote: > >> maybe "supertype". It is one char shorter .. somewhere is term > >> "supperclass,

Re: proposal: new polymorphic types - commontype and commontypearray

út 5. 3. 2019 v 15:35 odesílatel Tom Lane napsal: > David Steele writes: > > This thread has been very quiet for a month. I agree with Andres [1] > > that we should push this to PG13. > > I think the main thing it's blocked on is disagreement on what the > type name should be, which is kind of

Re: proposal: variadic argument support for least, greatest function

st 6. 3. 2019 v 16:24 odesílatel Chapman Flack napsal: > On 3/6/19 10:12 AM, Andrew Dunstan wrote: > > > Having reviewed the thread, I'm with Andres and Tom. Maybe though we > > should have a note somewhere to the effect that you can't use VARIADIC > > with these. > > Perhaps such a note belongs

Re: Re: proposal: plpgsql pragma statement

Hi čt 7. 3. 2019 v 8:03 odesílatel David Steele napsal: > On 2/4/19 8:12 PM, Pavel Stehule wrote: > > > > attached rebased patch > > This patch has gone through a few iterations but I don't think there's > any agreement on what it should look like. There&

Re: Re: [HACKERS] proposal: schema variables

čt 7. 3. 2019 v 9:10 odesílatel Fabien COELHO napsal: > > Hello David, > > > This patch hasn't receive any review in a while and I'm not sure if > that's > > because nobody is interested or the reviewers think it does not need any > more > > review. > > > > It seems to me that this patch as imple

Re: Re: [HACKERS] proposal: schema variables

Hi >> My strong opinion based on the underlying use case is that it that such >> session variables should be transactional by default, and Pavel strong >> opinion is that they should not, to be closer to Oracle comparable >> feature. > > It is closer to any known database Oracle, DB2, Firebird, M

Re: proposal: plpgsql pragma statement

čt 7. 3. 2019 v 14:40 odesílatel Andrew Dunstan < andrew.duns...@2ndquadrant.com> napsal: > > On 3/7/19 3:19 AM, Pavel Stehule wrote: > > Hi > > > > čt 7. 3. 2019 v 8:03 odesílatel David Steele > <mailto:da...@pgmasters.net>> napsal: > >

Re: proposal: plpgsql pragma statement

čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan < andrew.duns...@2ndquadrant.com> napsal: > > On 3/7/19 11:45 AM, Pavel Stehule wrote: > > > > > > > > > > I have looked at the latest patch, but it seems inadequate unless I'm > > mis

Re: proposal: plpgsql pragma statement

čt 7. 3. 2019 v 18:45 odesílatel Andrew Dunstan < andrew.duns...@2ndquadrant.com> napsal: > > On 3/7/19 12:41 PM, Pavel Stehule wrote: > > > > > > čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan > > > <mailto:andrew.duns...@2ndquadrant.com>> naps

Re: PostgreSQL vs SQL/XML Standards

Hi pá 8. 3. 2019 v 3:44 odesílatel Alvaro Herrera napsal: > On 2019-Mar-07, Alvaro Herrera wrote: > > > On 2019-Feb-11, Chapman Flack wrote: > > > > > xmltable-xpath-result-processing-bugfix-6.patch includes a > regress/expected > > > output for the no-libxml case that was left out of -5. > > >

Re: PostgreSQL vs SQL/XML Standards

pá 8. 3. 2019 v 3:44 odesílatel Alvaro Herrera napsal: > On 2019-Mar-07, Alvaro Herrera wrote: > > > On 2019-Feb-11, Chapman Flack wrote: > > > > > xmltable-xpath-result-processing-bugfix-6.patch includes a > regress/expected > > > output for the no-libxml case that was left out of -5. > > > > Pu

Re: PostgreSQL vs SQL/XML Standards

pá 8. 3. 2019 v 7:41 odesílatel Pavel Stehule napsal: > Hi > > pá 8. 3. 2019 v 3:44 odesílatel Alvaro Herrera > napsal: > >> On 2019-Mar-07, Alvaro Herrera wrote: >> >> > On 2019-Feb-11, Chapman Flack wrote: >> > >> > > xmltable-xpa

Re: PostgreSQL vs SQL/XML Standards

pá 8. 3. 2019 v 13:20 odesílatel Alvaro Herrera napsal: > On 2019-Mar-08, Pavel Stehule wrote: > > > looks like error in xmlXPathCompiledEval function, that produce little > bit > > broken result for XML_DOCUMENT_NODE type. I hadn't this problem with > > libx

Re: PostgreSQL vs SQL/XML Standards

pá 8. 3. 2019 v 15:31 odesílatel Alvaro Herrera napsal: > On 2019-Mar-08, Pavel Stehule wrote: > > > looks like error in xmlXPathCompiledEval function, that produce little > bit > > broken result for XML_DOCUMENT_NODE type. I hadn't this problem with > > libx

Re: PostgreSQL vs SQL/XML Standards

pá 8. 3. 2019 v 19:44 odesílatel Alvaro Herrera napsal: > On 2019-Mar-08, Alvaro Herrera wrote: > > > > Maybe we can call explicitly xmlFreeDoc instead xmlFreeNode > > > > > > some like > > > > > > if (cur_copy->type == XML_DOCUMENT_NODE) > > > xmlFreeDoc((xmlDocPtr) cur_copy); > > > else > > >

Re: PostgreSQL vs SQL/XML Standards

pá 8. 3. 2019 v 19:48 odesílatel Pavel Stehule napsal: > > > pá 8. 3. 2019 v 19:44 odesílatel Alvaro Herrera > napsal: > >> On 2019-Mar-08, Alvaro Herrera wrote: >> >> > > Maybe we can call explicitly xmlFreeDoc instead xmlFreeNode >> > >

Re: \describe*

Hi > Since this is now waiting for v13, there's a bit more time to entertain > the question of whether we'd rather have these in psql or in a new server > command DESCRIBE [verbose] [system], and if so, whether the output of that > would itself be query-able or not. > Including this feature in c

proposal: type info support functions for functions that use "any" type

Hi, Tom introduced supported functions for calculation function's selectivity. Still I have similar idea to use supported function for calculation function's parameter's types and function return type. Motivation: Reduce a necessity of overloading of functions. My motivation is related primary t

Re: proposal: plpgsql pragma statement

čt 7. 3. 2019 v 18:45 odesílatel Andrew Dunstan < andrew.duns...@2ndquadrant.com> napsal: > > On 3/7/19 12:41 PM, Pavel Stehule wrote: > > > > > > čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan > > > <mailto:andrew.duns...@2ndquadrant.com>> naps

Re: proposal: plpgsql pragma statement

so 9. 3. 2019 v 22:17 odesílatel Pavel Stehule napsal: > > > čt 7. 3. 2019 v 18:45 odesílatel Andrew Dunstan < > andrew.duns...@2ndquadrant.com> napsal: > >> >> On 3/7/19 12:41 PM, Pavel Stehule wrote: >> > >> > >> > čt 7. 3. 2019 v

Re: proposal: variadic argument support for least, greatest function

po 11. 3. 2019 v 18:04 odesílatel David Steele napsal: > On 3/11/19 6:43 PM, Andrew Dunstan wrote: > > > > On 3/6/19 10:24 AM, Chapman Flack wrote: > >> On 3/6/19 10:12 AM, Andrew Dunstan wrote: > >> > >>> Having reviewed the thread, I'm with Andres and Tom. Maybe though we > >>> should have a no

Re: ToDo: show size of partitioned table

st 13. 3. 2019 v 8:02 odesílatel Amit Langote napsal: > On 2019/02/22 1:41, Pavel Stehule wrote: > > čt 21. 2. 2019 v 0:56 odesílatel Justin Pryzby > > napsal: > > > >> On Sat, Feb 16, 2019 at 10:52:35PM +0100, Pavel Stehule wrote: > >>> I like you

Re: PostgreSQL vs SQL/XML Standards

Hi pá 8. 3. 2019 v 19:44 odesílatel Alvaro Herrera napsal: > On 2019-Mar-08, Alvaro Herrera wrote: > > > > Maybe we can call explicitly xmlFreeDoc instead xmlFreeNode > > > > > > some like > > > > > > if (cur_copy->type == XML_DOCUMENT_NODE) > > > xmlFreeDoc((xmlDocPtr) cur_copy); > > > else >

string_to_array, array_to_string function without separator

Hi I propose mentioned functions without specified separator. In this case the string is transformed to array of chars, in second case, the array of chars is transformed back to string. Comments, notes? Regards Pavel

Re: string_to_array, array_to_string function without separator

pá 15. 3. 2019 v 15:03 odesílatel David Fetter napsal: > On Fri, Mar 15, 2019 at 05:04:02AM +0100, Pavel Stehule wrote: > > Hi > > > > I propose mentioned functions without specified separator. In this case > the > > string is transformed to array of chars, in sec

Re: string_to_array, array_to_string function without separator

pá 15. 3. 2019 v 16:59 odesílatel Chapman Flack napsal: > On 3/15/19 11:46 AM, Pavel Stehule wrote: > > pá 15. 3. 2019 v 15:03 odesílatel David Fetter > napsal: > >> Whatever optimizations you have in mind for this, could they also work > >> for string_to_array() a

Re: string_to_array, array_to_string function without separator

pá 15. 3. 2019 v 17:16 odesílatel Tom Lane napsal: > Chapman Flack writes: > > So the proposal seems roughly equivalent to making string_to_array's > > second parameter optional default null, and array_to_string's second > > parameter optional default ''. > > In that case why bother? It'll just

Re: string_to_array, array_to_string function without separator

pá 15. 3. 2019 v 17:54 odesílatel Chapman Flack napsal: > On 3/15/19 12:26 PM, Pavel Stehule wrote: > > you use string_to_array function without separator, then only one > possible > > semantic is there - separation by chars. > > Other languages can and do specify

Re: string_to_array, array_to_string function without separator

pá 15. 3. 2019 v 18:30 odesílatel Chapman Flack napsal: > On 3/15/19 12:59 PM, Pavel Stehule wrote: > > for this proposal "char" != byte > > > > result[n] = substring(str FROM n FOR 1) > > I think that's what string_to_array(..., null) already does:

Re: jsonpath

so 16. 3. 2019 v 10:36 odesílatel Alexander Korotkov < a.korot...@postgrespro.ru> napsal: > On Thu, Mar 14, 2019 at 12:07 PM Alexander Korotkov > wrote: > > On Sun, Mar 10, 2019 at 1:51 PM Alexander Korotkov > > wrote: > > > On Wed, Mar 6, 2019 at 12:40 AM Nikita Glukhov < > n.glu...@postgrespro

Re: [HACKERS] generated columns

Hi po 18. 3. 2019 v 8:35 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > Here is an updated patch with just the "stored" functionality, as > discussed. > > The actual functionality is much smaller now, contained in the executor. > Everything else is mostly DDL support,

Re: jsonpath

po 18. 3. 2019 v 21:23 odesílatel Tom Lane napsal: > Alexander Korotkov writes: > > On Mon, Mar 18, 2019 at 10:08 PM Tom Lane wrote: > >> Just another minor bitch about this patch: jsonpath_scan.l has > introduced > >> a typedef called "keyword". This is causing pgindent to produce > seriously

Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested I read a discussion and I think so currently implemented behave (by l

Re: Proposal to suppress errors thrown by to_reg*()

st 20. 3. 2019 v 5:55 odesílatel Takuma Hoshiai napsal: > On Wed, 20 Mar 2019 09:48:59 +0900 (Tokyo Standard Time) > Kyotaro HORIGUCHI wrote: > > > At Wed, 20 Mar 2019 07:13:28 +0900 (JST), Tatsuo Ishii < > is...@sraoss.co.jp> wrote in < > 20190320.071328.48576044685486.t-is...@sraoss.co.jp>

Re: [HACKERS] proposal: schema variables

Hi rebase against current master Regards Pavel schema-variables-20190324.patch.gz Description: application/gzip

Re: [HACKERS] proposal: schema variables

ne 24. 3. 2019 v 10:25 odesílatel Erik Rijkers napsal: > On 2019-03-24 06:57, Pavel Stehule wrote: > > Hi > > > > rebase against current master > > > > I ran into this: > > (schema 'varschema2' does not exist): > > drop variable varschema

Re: Re: proposal: plpgsql pragma statement

po 25. 3. 2019 v 8:38 odesílatel David Steele napsal: > Hi Pavel, > > On 3/10/19 8:39 PM, Pavel Stehule wrote: > > Here is pragma patch with demo > We're still not getting real review for this patch and Andrew seems as > skeptical as anyone that this is the right w

Re: [HACKERS] proposal: schema variables

Hi ne 24. 3. 2019 v 6:57 odesílatel Pavel Stehule napsal: > Hi > > rebase against current master > fixed issue IF NOT EXISTS & related regress tests Regards Pavel > Regards > > Pavel > schema-variables-20190326.patch.gz Description: application/gzip

Re: [HACKERS] proposal: schema variables

po 25. 3. 2019 v 20:40 odesílatel Erik Rijkers napsal: > On 2019-03-24 10:32, Pavel Stehule wrote: > > ne 24. 3. 2019 v 10:25 odesílatel Erik Rijkers napsal: > > > >> On 2019-03-24 06:57, Pavel Stehule wrote: > >> > Hi > >> > > >>

Re: [HACKERS] generated columns

Hi út 26. 3. 2019 v 14:33 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2019-03-20 03:51, Michael Paquier wrote: > > On Mon, Mar 18, 2019 at 03:14:09PM +0100, Pavel Stehule wrote: > >> postgres=# update foo set name = 'bbbxx' wher

Re: [HACKERS] generated columns

út 26. 3. 2019 v 19:52 odesílatel Pavel Stehule napsal: > Hi > > út 26. 3. 2019 v 14:33 odesílatel Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> napsal: > >> On 2019-03-20 03:51, Michael Paquier wrote: >> > On Mon, Mar 18, 2019 at 03:14:09PM +0100,

Re: [HACKERS] generated columns

Hi út 26. 3. 2019 v 14:33 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2019-03-20 03:51, Michael Paquier wrote: > > On Mon, Mar 18, 2019 at 03:14:09PM +0100, Pavel Stehule wrote: > >> postgres=# update foo set name = 'bbbxx' wher

Re: ToDo: show size of partitioned table

čt 28. 3. 2019 v 10:12 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2019-03-22 01:21, Amit Langote wrote: > > On 2019/03/22 2:23, David Steele wrote: > >> On 3/14/19 6:19 AM, Amit Langote wrote: > >>> On 2019/03/14 2:11, Pave

Re: PostgreSQL pollutes the file system

pá 29. 3. 2019 v 19:50 odesílatel Christoph Berg napsal: > Re: Tom Lane 2019-03-29 <19517.1553876...@sss.pgh.pa.us> > > >> Or perhaps better, allow pg_ctl to grow new subcommands for those > > >> tasks? > > > > > We'd need to be careful to somehow delineate commands that need access > > > to the

Re: [HACKERS] generated columns

so 30. 3. 2019 v 9:03 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2019-03-26 20:50, Pavel Stehule wrote: > > It is great feature and I'll mark this feature as ready for commit > > Committed, thanks. > great feature, it reduce some n

Re: SQL/JSON: JSON_TABLE

Hi út 16. 7. 2019 v 16:06 odesílatel Nikita Glukhov napsal: > On 29.06.2019 8:40, Pavel Stehule wrote: > > Hi > > so 29. 6. 2019 v 7:26 odesílatel Nikita Glukhov > napsal: > >> Attached 36th version of patches rebased onto jsonpath v36. >> > > I cannot t

Re: dropdb --force

čt 25. 7. 2019 v 5:11 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > [ drop-database-force-20190708.patch ] > > I took a brief look at this, but I don't think it's really close to > being committable. > > * The documentation claims FORCE will fail

Re: proposal: type info support functions for functions that use "any" type

pá 26. 7. 2019 v 22:03 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > so 9. 3. 2019 v 7:22 odesílatel Pavel Stehule > > napsal: > >> Tom introduced supported functions for calculation function's > selectivity. > >> Still I have similar idea

Re: proposal: type info support functions for functions that use "any" type

pá 26. 7. 2019 v 22:53 odesílatel Tom Lane napsal: > I wrote: > > TBH, I don't like this proposal one bit. As far as I can see, the idea > > is to let a function's support function redefine the function's declared > > argument and result types on-the-fly according to no predetermined rules, > >

Re: psql's meta command \d is broken as of 12 beta2.

Hi po 5. 8. 2019 v 13:35 odesílatel Dmitry Igrishin napsal: > Hi, > > Sorry if this report is duplicate but there is no column relhasoids in > pg_catalog.pg_class required by the underlying query of the \d meta > command of psql. > do you use psql from this release? The psql client should be

Re: psql's meta command \d is broken as of 12 beta2.

po 5. 8. 2019 v 13:46 odesílatel Dmitry Igrishin napsal: > пн, 5 авг. 2019 г. в 14:42, Pavel Stehule : > > > > Hi > > > > > > po 5. 8. 2019 v 13:35 odesílatel Dmitry Igrishin > napsal: > >> > >> Hi, > >> > >>

is necessary to recheck cached data in fn_extra?

Hi I should to use a cache accessed via fn_extra. There will be stored data about function parameters (types). If I understand correctly, these data should be stable in query, and then recheck is not necessary. Is it true? Regards Pavel

Re: proposal: type info support functions for functions that use "any" type

čt 1. 8. 2019 v 11:01 odesílatel Thomas Munro napsal: > On Sat, Jul 27, 2019 at 5:45 PM Pavel Stehule > wrote: > > pá 26. 7. 2019 v 22:53 odesílatel Tom Lane napsal: > >> I wrote: > >> > TBH, I don't like this proposal one bit. As far as I can see, th

Re: proposal: type info support functions for functions that use "any" type

Hi pá 26. 7. 2019 v 22:53 odesílatel Tom Lane napsal: > I wrote: > > TBH, I don't like this proposal one bit. As far as I can see, the idea > > is to let a function's support function redefine the function's declared > > argument and result types on-the-fly according to no predetermined rules,

Re: is necessary to recheck cached data in fn_extra?

st 7. 8. 2019 v 17:39 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I should to use a cache accessed via fn_extra. There will be stored data > > about function parameters (types). If I understand correctly, these data > > should be stable in query, and then rec

Re: is necessary to recheck cached data in fn_extra?

st 7. 8. 2019 v 18:39 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > st 7. 8. 2019 v 17:39 odesílatel Tom Lane napsal: > >> I wouldn't trust that. You don't really know what the lifespan of > >> a fn_extra cache is. > > > fn_extra ca

Re: [HACKERS] proposal: schema variables

Hi just rebase Regards Pavel schema-variables-rebase-20190810.patch.gz Description: application/gzip

Re: Global temporary tables

Hi > There is one more problem with global temporary tables for which I do not > know good solution now: collecting statistic. > As far as each backend has its own data, generally them may need different > query plans. > Right now if you perform "analyze table" in one backend, then it will > affe

Re: errbacktrace

Hi so I agree with unconditionally defining that symbol. > > Nitpicking dept: I think in these tests: > > + if (!edata->backtrace && > + edata->funcname && > + backtrace_function[0] && > + strcmp(backtrace_function, edata->funcname) == 0) > + set_backtrace(edata, 2); > >

Re: Global temporary tables

po 12. 8. 2019 v 18:19 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > Hi, > > On 11.08.2019 10:14, Pavel Stehule wrote: > > > Hi > > >> There is one more problem with global temporary tables for which I do not >> know good soluti

Re: errbacktrace

po 12. 8. 2019 v 19:06 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2019-08-12 13:19, Pavel Stehule wrote: > > If I understand well, backtrace is displayed only when edata->funcname > > is same like backtrace_function GUC. Isn't it

Re: proposal: type info support functions for functions that use "any" type

Hi rebase Pavel diff --git a/contrib/decode/.gitignore b/contrib/decode/.gitignore new file mode 100644 index 00..5dcb3ff972 --- /dev/null +++ b/contrib/decode/.gitignore @@ -0,0 +1,4 @@ +# Generated subdirectories +/log/ +/results/ +/tmp_check/ diff --git a/contrib/decode/Makefile b/cont

Re: Global temporary tables

pá 16. 8. 2019 v 16:12 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > I did more investigations of performance of global temp tables with shared > buffers vs. vanilla (local) temp tables. > > 1. Combination of persistent and temporary tables in the same query. > > Preparatio

Re: Global temporary tables

ne 18. 8. 2019 v 9:02 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 16.08.2019 20:17, Pavel Stehule wrote: > > > > pá 16. 8. 2019 v 16:12 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > >> I did

Re: Global temporary tables

po 19. 8. 2019 v 13:16 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 19.08.2019 11:51, Konstantin Knizhnik wrote: > > > > On 18.08.2019 11:28, Pavel Stehule wrote: > > > > ne 18. 8. 2019 v 9:02 odesílatel Konstantin Knizhni

Re: Global temporary tables

> Certainly, default (small) temp buffer size plays roles. > But it this IPC host this difference is not so important. > Result with local temp tables and temp_buffers = 1GB: 859k TPS. > It is little bit unexpected result.I understand so it partially it is generic problem access to smaller dedicat

Re: Make SQL/JSON error code names match SQL standard

út 20. 8. 2019 v 10:49 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > I propose the attached patch to make the new SQL/JSON error code names > match the SQL standard. The existing minor differences don't seem > necessary. > +1 Pavel > > -- > Peter Eisentraut

Re: Global temporary tables

út 20. 8. 2019 v 16:51 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 19.08.2019 18:53, Pavel Stehule wrote: > > > > >> Certainly, default (small) temp buffer size plays roles. >> But it this IPC host this difference is not

Re: Global temporary tables

út 20. 8. 2019 v 18:42 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 20.08.2019 19:06, Pavel Stehule wrote: > > > > As I wrote at the beginning of this thread, one of the problems with >> temporary table sis that it is not possible

Re: Why overhead of SPI is so large?

čt 22. 8. 2019 v 17:51 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > Some more information... > First of all I found out that marking PL/pgSQL function as immutable > significantly increase speed of its execution: > 19808 ms vs. 27594. It happens because exec_eval_simple_ex

Re: Why overhead of SPI is so large?

pá 23. 8. 2019 v 11:05 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 22.08.2019 18:56, Pavel Stehule wrote: > > > > čt 22. 8. 2019 v 17:51 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > >> Some mo

Re: Why overhead of SPI is so large?

pá 23. 8. 2019 v 13:21 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 23.08.2019 12:10, Pavel Stehule wrote: > > > > pá 23. 8. 2019 v 11:05 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > >> &

Re: Why overhead of SPI is so large?

so 24. 8. 2019 v 18:01 odesílatel David Fetter napsal: > On Fri, Aug 23, 2019 at 11:10:28AM +0200, Pavel Stehule wrote: > > pá 23. 8. 2019 v 11:05 odesílatel Konstantin Knizhnik < > > k.knizh...@postgrespro.ru> napsal: > > > > > > > > &

Re: doc: update PL/pgSQL sample loop function

Hi čt 29. 8. 2019 v 5:03 odesílatel Ian Barwick napsal: > Hi > > Here: > > > https://www.postgresql.org/docs/current/plpgsql-control-structures.html#PLPGSQL-RECORDS-ITERATING > > we have a sample PL/PgSQL function (dating from at least 7.2) demonstrating > query result loops, which refreshes som

Re: Proposal: roll pg_stat_statements into core

Hi ne 1. 9. 2019 v 20:00 odesílatel David Fetter napsal: > Folks, > > I'd like to $Subject, on by default, with a switch to turn it off for > those really at the outer edges of performance. Some reasons include: > > - It's broadly useful. > - Right now, the barrier for turning it on is quite hig

Re: Proposal: roll pg_stat_statements into core

ne 1. 9. 2019 v 20:48 odesílatel David Fetter napsal: > On Sun, Sep 01, 2019 at 08:12:15PM +0200, Pavel Stehule wrote: > > Hi > > > > ne 1. 9. 2019 v 20:00 odesílatel David Fetter napsal: > > > > > Folks, > > > > > > I'd like t

Re: dropdb --force

út 3. 9. 2019 v 18:46 odesílatel Alvaro Herrera napsal: > On 2019-Jul-25, Pavel Stehule wrote: > > > čt 25. 7. 2019 v 5:11 odesílatel Tom Lane napsal: > > > > > Pavel Stehule writes: > > > > * I'm concerned that the proposed syntax is not future

Re: [HACKERS] SQL/JSON in PostgreSQL

2018-01-02 3:04 GMT+01:00 Nikita Glukhov : > On 29.11.2017 05:24, Michael Paquier wrote: > > On Wed, Nov 15, 2017 at 10:17 AM, Nikita Glukhov >> wrote: >> >>> Attached the new version of the patches where displaying of SQL/JSON >>> constructor nodes was fixed. I decided not to invent new nodes b

Re: [HACKERS] SQL/JSON in PostgreSQL

2018-01-02 3:04 GMT+01:00 Nikita Glukhov : > On 29.11.2017 05:24, Michael Paquier wrote: > > On Wed, Nov 15, 2017 at 10:17 AM, Nikita Glukhov >> wrote: >> >>> Attached the new version of the patches where displaying of SQL/JSON >>> constructor nodes was fixed. I decided not to invent new nodes b

Re: [HACKERS] SQL/JSON in PostgreSQL

Hi regress tests fails Regards Pavel regression.diffs Description: Binary data

Re: [HACKERS] SQL procedures

2018-01-02 17:47 GMT+01:00 Tom Lane : > Robert Haas writes: > > I agree that we need this, but using prorettype = InvalidOid to do it > > might not be the best way, because it only works for procedures that > > don't return anything. If a procedure could return, say, an integer, > > Good point,

Re: [HACKERS] SQL/JSON in PostgreSQL

2018-01-02 21:39 GMT+01:00 Andrew Dunstan : > > > On 01/02/2018 02:44 PM, Oleg Bartunov wrote: > > On Tue, Jan 2, 2018 at 10:47 AM, Pavel Stehule > wrote: > > >> I am looking on this patch set and it looks very well. > >> > >> Personally I disli

Re: [HACKERS] SQL/JSON in PostgreSQL

I have removed all extra features from the patch set, they can be found in our > github repository: https://github.com/postgrespro/sqljson/tree/sqljson_ext > . > > Now there are 10 patches which have the following dependencies: > > 1: > 2: 1 > 3: 2 > 4: 2 > 5: > 6: > 7: 2, 5, 6 > 8: 7, 4 > 9: 7 >

Re: [HACKERS] SQL/JSON in PostgreSQL

2018-01-03 17:04 GMT+01:00 Oleg Bartunov : > > > On 3 Jan 2018 00:23, "Andrew Dunstan" > wrote: > > > > On 01/02/2018 05:04 PM, Nikita Glukhov wrote: > > > > I have removed all extra features from the patch set, they can be > > found in our > > github repository: > > https://github.com/postgrespr

Re: [HACKERS] SQL/JSON in PostgreSQL

Hi I am checking the JSONPath related code Questions, notes: 1. jsonpath operators are not consistent with any other .. json, xml .. I am missing ?, @> operátors 2. documentation issue - there is "'{"a":[1,2,3,4,5]}'::json *? '$.a[*] ? (@ > 2)'" - operator *? doesn't exists 3. operator @~ looks

Re: [HACKERS] SQL/JSON in PostgreSQL

2018-01-06 22:02 GMT+01:00 Oleg Bartunov : > On Sat, Jan 6, 2018 at 8:22 AM, Pavel Stehule > wrote: > > Hi > > > > I am checking the JSONPath related code > > > > Questions, notes: > > > > 1. jsonpath operators are not consistent with any other ..

Re: [HACKERS] SQL/JSON in PostgreSQL

Hi I try jsonpath on json { "book": [ { "title": "Beginning JSON", "author": "Ben Smith", "price": 49.99 }, { "title": "JSON at Work", "author": "Tom Marrs", "price": 29.99 },

Re: [HACKERS] SQL/JSON in PostgreSQL

2018-01-06 22:23 GMT+01:00 Nikita Glukhov : > On 07.01.2018 00:22, Pavel Stehule wrote: > > Hi > > I try jsonpath on json > > { > "book": > [ > { > "title": "Beginning JSON", &g

Re: [HACKERS] plpgsql - additional extra checks

Hi 2018-01-07 0:59 GMT+01:00 Stephen Frost : > Greetings Pavel, > > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > 2017-11-30 3:44 GMT+01:00 Michael Paquier : > > > At least documentation needs patching, or this is going to generate > > > warnings on HEAD

Re: jsonpath

2018-01-07 20:31 GMT+01:00 Andrew Dunstan : > > Next up in the proposed SQL/JSON feature set I will review the three > jsonpath patches. These are attached, extracted from the patch set > Nikita posted on Jan 2nd. > > > Note that they depend on the TZH/TZM patch (see separate email thread). > I'd

Re: jsonpath

2018-01-07 21:14 GMT+01:00 Andrew Dunstan : > > > On 01/07/2018 03:00 PM, Pavel Stehule wrote: > > > > > > 2018-01-07 20:31 GMT+01:00 Andrew Dunstan > > mailto:andrew.duns...@2ndquadrant.com > >>: > > > > > > Next up

Re: jsonpath

2018-01-07 21:20 GMT+01:00 Andrew Dunstan : > > > On 01/07/2018 03:16 PM, Pavel Stehule wrote: > > > > > > 2018-01-07 21:14 GMT+01:00 Andrew Dunstan > > mailto:andrew.duns...@2ndquadrant.com > >>: > > > > > > > > On 01/07/2018

Re: to_timestamp TZH and TZM format specifiers

Hi 2018-01-08 1:22 GMT+01:00 Nikita Glukhov : > On 03.01.2018 21:34, Tom Lane wrote: > > Andrew Dunstan writes: >> >>> This small and simple standalone patch extracted from the SQL/JSON work >>> would allow the user to supply a string with a time zone specified as >>> hh:mm thus: >>> SELECT

Re: to_timestamp TZH and TZM format specifiers

2018-01-09 19:46 GMT+01:00 Pavel Stehule : > Hi > > 2018-01-08 1:22 GMT+01:00 Nikita Glukhov : > >> On 03.01.2018 21:34, Tom Lane wrote: >> >> Andrew Dunstan writes: >>> >>>> This small and simple standalone patch extracted from the SQL/JSON wor

Re: to_timestamp TZH and TZM format specifiers

2018-01-09 19:52 GMT+01:00 Andrew Dunstan : > > > On 01/09/2018 01:46 PM, Pavel Stehule wrote: > > > > > > I checked this patch and I think so it is correct. > > > > 1. all tests passed > > 2. no problems with patching and compilation > > 3. th

<    1   2   3   4   5   6   7   8   9   10   >