Hi Tom,
While setting timezone using SET command (say GMT+3:30), postgres sometimes
crashes randomly.
After debugging into the code, it is observed that if tzload() call fails in
pg_tzset() for whatever reason, the returned value of the function then have
garbage values for state variable. And
Oops...
Forgot to attach the patch.
Attached here
Thanks
On Thu, Mar 11, 2010 at 4:21 PM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Hi Tom,
While setting timezone using SET command (say GMT+3:30), postgres sometimes
crashes randomly.
After debugging into the code
Hi Dave,
On Thu, Mar 11, 2010 at 4:38 PM, Dave Page dp...@pgadmin.org wrote:
On Thu, Mar 11, 2010 at 10:51 AM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
PFA, patch which will bring us up-to date to 2010c.
Hi Jeevan,
We're already up to 2010e in CVS:
http
Hi Tom,
On Thu, Mar 11, 2010 at 8:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
While setting timezone using SET command (say GMT+3:30), postgres
sometimes
crashes randomly.
I can't reproduce that:
regression=# SET TimeZone = 'GMT+3:30
Hi,
With PG84, I have tried something like this which seem incorrect to me.
# SELECT '' AS to_number_2, to_number('-347,58', '99G999');
to_number_2 | to_number
-+---
| -3458
(1 row)
After browsing the code (numeric_to_number), I have found that number
Hi,
On Sat, Sep 19, 2009 at 1:52 AM, Brendan Jurd dire...@gmail.com wrote:
2009/9/19 Tom Lane t...@sss.pgh.pa.us:
Should we have it throw an error if the input corresponding to a G
symbol doesn't match the expected group separator? I'm concerned that
that would break applications that
Hi,
On Mon, Sep 21, 2009 at 12:36 PM, Brendan Jurd dire...@gmail.com wrote:
2009/9/21 Jeevan Chalke jeevan.cha...@enterprisedb.com:
Oracle returns 19-SEP-09 irrespective of the format.
Here in PG, we have getting the proper date irrespective of the format as
Oracle. But in the case
Hi,
I gone through the discussion for this patch and here is my review:
The main aim of this patch is to reduce the number of log lines. It is also
suggested to use an options to provide the interval but few of us are not
much agree on it. So final discussion ended at keeping 5 sec interval
Hi,
On Tue, Nov 20, 2012 at 12:08 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 19.11.2012 11:59, Jeevan Chalke wrote:
Hi,
I gone through the discussion for this patch and here is my review:
The main aim of this patch is to reduce the number of log lines. It is
also suggested to use
On Sun, Dec 9, 2012 at 8:11 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 20.11.2012 08:22, Jeevan Chalke wrote:
Hi,
On Tue, Nov 20, 2012 at 12:08 AM, Tomas Vondra t...@fuzzy.cz
mailto:t...@fuzzy.cz wrote:
On 19.11.2012 11:59, Jeevan Chalke wrote:
Hi,
I gone
provide updated patch for final code review.
Thanks
Tomas
On 11.12.2012 10:23, Jeevan Chalke wrote:
On Sun, Dec 9, 2012 at 8:11 AM, Tomas Vondra t...@fuzzy.cz
mailto:t...@fuzzy.cz wrote:
On 20.11.2012 08:22, Jeevan Chalke wrote:
Hi,
On Tue, Nov
Looks good to me.
Will mark Ready for Committer
Thanks
On Thu, Dec 20, 2012 at 2:30 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 19.12.2012 06:30, Jeevan Chalke wrote:
On Mon, Dec 17, 2012 at 5:37 AM, Tomas Vondra t...@fuzzy.cz
mailto:t...@fuzzy.cz wrote:
Hi,
attached
Hi Robert / Tom
I think to support GiST with unlogged table we need to do three things:
1. Teach the buffer manager that the LSN of a page not marked
BM_PERMANENT can be ignored
2. Teach GetXLogRecPtrForTemp() to allocate fake LSNs for GiST buffers
using a 64-bit, counter that is persisted
Hi Peter,
Idea is really very good.
About the patch:
Patch looks good to me.
Applied cleanly on latest sources. make / make install / make check /
initdb everything works well.
Tested with few options and it is working well.
However, I think you need to add this in docs. Letting people know
On Thu, Jan 10, 2013 at 11:07 PM, Andrew Dunstan and...@dunslane.netwrote:
On 01/10/2013 12:35 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I think there's a very good case for breaking the nexus between
PRETTYFLAG_PAREN and PRETTYFLAG_INDENT+line wrapping for views. Only
On Wed, Jan 16, 2013 at 3:24 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 15, 2013 at 4:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think that might be acceptable from a performance point of view -
after all, if the index is unlogged,
WRAP_COLUMN_DEFAULT by default. I will
keep that in code committors plate. Rest of the code changes looks good to
me.
Thanks
On Sun, Jan 27, 2013 at 6:23 PM, Marko Tiikkaja pgm...@joh.to wrote:
On Fri, 18 Jan 2013 07:46:21 +0100, Jeevan Chalke
jeevan.chalke@enterprisedb.**com jeevan.cha...@enterprisedb.com
Hi Marko,
On Mon, Jan 28, 2013 at 5:01 PM, Marko Tiikkaja pgm...@joh.to wrote:
On 1/28/13 12:14 PM, Jeevan Chalke wrote:
I could not apply the patch with git apply, but able to apply it by patch
-p1 command.
IME that's normal for patches that went through filterdiff. I do: git
diff
Hi Heikki,
On Mon, Jan 28, 2013 at 2:34 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 23.01.2013 17:30, Robert Haas wrote:
On Wed, Jan 23, 2013 at 4:04 AM, Jeevan Chalke
jeevan.chalke@enterprisedb.**com jeevan.cha...@enterprisedb.com
wrote:
I guess my earlier patch, which
Hi Marko,
On Wed, Jan 30, 2013 at 2:07 AM, Marko Tiikkaja pgm...@joh.to wrote:
On Tue, 29 Jan 2013 10:18:51 +0100, Jeevan Chalke
jeevan.chalke@enterprisedb.**com jeevan.cha...@enterprisedb.com wrote:
That's fine. I am not at all pointing that to you. Have a look at this:
Here's
Hi Tom,
Issue is on Windows:
If you see in attached failure.out file, (after running failure.sql) we are
getting ERROR: invalid
byte sequence for encoding UTF8: 0xe59aff error. Please note that byte
sequence we got from database is e5 9a ff, where as actual byte sequence for
the wide character
On Wed, Jun 8, 2011 at 6:22 AM, Robert Haas robertmh...@gmail.com wrote:
2011/6/7 Jeevan Chalke jeevan.cha...@enterprisedb.com:
since we smash the identifier to lower case using
downcase_truncate_identifier() function, the solution is to make this
function should be wide-char aware, like
Hi Tom,
While going through few test-cases, I found that we cannot have two opened
cursors with same name even though they are in two different functions. Here
is what I mean:
1. I have two functions func1 and func2.
2. func1 calls func2
3. Both has cursor with same name, say mycursor
4. Somehow
On Tue, Aug 16, 2011 at 7:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
1. I have two functions func1 and func2.
2. func1 calls func2
3. Both has cursor with same name, say mycursor
4. Somehow I forgot closing it
5. executing func1
On Thu, Jan 31, 2013 at 4:40 PM, Dimitri Fontaine dimi...@2ndquadrant.frwrote:
Andrew Dunstan and...@dunslane.net writes:
Well, we could actually set the wrap value to 0, which would mean always
wrap. That wouldn't be making any assumption about the user's terminal
window size ;-)
+1
Hi,
Any review comments on this ?
On Tue, Jan 29, 2013 at 6:03 PM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Hi Heikki,
On Mon, Jan 28, 2013 at 2:34 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 23.01.2013 17:30, Robert Haas wrote:
On Wed, Jan 23, 2013 at 4:04
Hi Heikki,
On Mon, Feb 11, 2013 at 7:28 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 11.02.2013 08:44, Jeevan Chalke wrote:
Hi,
Any review comments on this ?
Sorry for the delay.
I did some minor cleanup on this. I added code to pg_resetxlog and
pg_controldata to reset
Hi,
I have observed that following sequence is causing server crash.
CREATE MATERIALIZED VIEW temp_class_mv AS
SELECT * FROM pg_class
WITH NO DATA;
CREATE OR REPLACE FUNCTION test_refresh_mv()
RETURNS int
AS $$
BEGIN
REFRESH MATERIALIZED VIEW temp_class_mv;
return 1;
END; $$ LANGUAGE
On Mon, Apr 22, 2013 at 6:41 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-04-22 18:35:04 +0530, Jeevan Chalke wrote:
Hi,
I have observed that following sequence is causing server crash.
CREATE MATERIALIZED VIEW temp_class_mv AS
SELECT * FROM pg_class
WITH NO DATA
Hi Tom,
Since we are close to release, we should not have crashes like this.
Please have a look. My patch may not be correct as I haven't looked closely.
Thanks
On Mon, Apr 22, 2013 at 7:28 PM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
On Mon, Apr 22, 2013 at 6:41 PM, Andres
On Tue, Apr 23, 2013 at 7:01 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Apr 23, 2013 at 7:18 AM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Hi Tom,
Since we are close to release, we should not have crashes like this.
huh? we are not even in beta yet
I mean, beta
On Wed, Apr 24, 2013 at 3:04 AM, Kevin Grittner kgri...@ymail.com wrote:
Jeevan Chalke jeevan.cha...@enterprisedb.com wrote:
On Mon, Apr 22, 2013 at 6:41 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-04-22 18:35:04 +0530, Jeevan Chalke wrote:
I have observed that following
Hi David,
I hope this is the latest patch to review, right ?
I am going to review it.
I have gone through the discussion on this thread and I agree with Stephen
Frost that it don't add much improvements as such but definitely it is
going to be easy for contributors in this area as they don't
Hi Mark,
Is this the latest patch you are targeting for 9.4 CF1 ?
I am going to review it.
From the comment, here is one issue you need to resolve first:
*** exec_eval_datum(PLpgSQL_execstate *estat
*** 4386,4396
errmsg(record \%s\ has no field
On Tue, Jun 25, 2013 at 11:11 AM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Hi David,
I hope this is the latest patch to review, right ?
I am going to review it.
I have gone through the discussion on this thread and I agree with Stephen
Frost that it don't add much improvements
On Wed, Jun 26, 2013 at 7:49 AM, Mark Wong mark...@gmail.com wrote:
On Tue, Jun 25, 2013 at 1:38 AM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Hi Mark,
Is this the latest patch you are targeting for 9.4 CF1 ?
I am going to review it.
From the comment, here is one issue
Hi Pavel
On Sat, Jan 26, 2013 at 9:22 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello Tom
you did comment
! * Non-null argument had better be an array.
The parser doesn't
! * enforce this for VARIADIC ANY functions
(maybe it should?), so
!
nothing harmful as such, so you can
ignore this review comment but I thought it worth mentioning it.
Thanks
On Thu, Jun 27, 2013 at 12:35 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
remastered version
Regards
Pavel
2013/6/26 Jeevan Chalke jeevan.cha...@enterprisedb.com:
Hi Pavel
Hi Pavel,
On Fri, Jun 28, 2013 at 2:53 AM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
2013/6/27 Jeevan Chalke jeevan.cha...@enterprisedb.com:
Hi Pavel,
I had a look over your new patch and it looks good to me.
My review comments on patch:
1. It cleanly applies with patch
On Mon, Jul 1, 2013 at 6:16 AM, David Fetter da...@fetter.org wrote:
On Fri, Jun 28, 2013 at 01:28:35PM -0400, Peter Eisentraut wrote:
On 6/28/13 11:30 AM, Robert Haas wrote:
On Fri, Jun 28, 2013 at 10:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Fetter da...@fetter.org writes:
On Mon, Jul 1, 2013 at 8:36 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
2013/6/29 Pavel Stehule pavel.steh...@gmail.com:
Hello
updated patch - precious Assert, more comments
Regards
Pavel
stripped
Thanks.
Patch looks good to me now.
Revalidated and didn't see any issue
Hi Tom,
Following example does not work as expected:
-- Should return TRUE but returning FALSE
SELECT 'Programmer' ~ '(\w).*?\1' as t;
-- Should return P, a and er i.e. 3 rows but returning just one row with
-- value Programmer
SELECT REGEXP_SPLIT_TO_TABLE('Programmer','(\w).*?\1');
Initially
Hi Tom,
On Sat, Jul 13, 2013 at 10:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
Following example does not work as expected:
-- Should return TRUE but returning FALSE
SELECT 'Programmer' ~ '(\w).*?\1' as t;
This is clearly
Hi,
While playing with regular expression I found some strange behavior of
regexp_matches() function.
Consider following sql query and its output:
postgres=# select regexp_matches('1' || chr(10) || '2' || chr(10) || '3' ||
chr(10) || '4', '^', 'mg');
regexp_matches
{}
{}
{}
Oops forgot patch.
Attached now.
On Wed, Jul 31, 2013 at 6:03 PM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Hi,
While playing with regular expression I found some strange behavior of
regexp_matches() function.
Consider following sql query and its output:
postgres=# select
On Wed, Jul 31, 2013 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
Oops forgot patch.
Attached now.
Hmm ... I think the logic change is good, but two demerits for not fixing
the adjacent comment.
I had a look over comments
On Thu, Aug 1, 2013 at 12:25 PM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
On Wed, Jul 31, 2013 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
Oops forgot patch.
Attached now.
Hmm ... I think the logic change is good
Hi Marko,
I have reviewed this patch.
1. Patch applies well.
2. make and make install is fine
3. make check is fine too.
But as Peter pointed out plperl regression tests are failing.
I just did grep on .sql files and found following files which has RAISE
statement into it. These files too need
Hi Pavel,
I have reviewed your patch.
Patch looks excellent and code changes match with similar constructs
elsewhere. That's great.
However, it was not applying with git apply command but able to apply it
with patch -p1 with some offsets. make and make install was smooth too.
Regression suite
On Wed, Sep 18, 2013 at 9:54 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
thank you,
I have no comments
Thanks.
Assigned it to committer.
Regards
Pavel
--
Jeevan B Chalke
Hi,
I had a look over this patch and here are my review points:
1. Patch applies cleanly.
2. make, make install and make check is good.
3. I did lot of random testing and didn't find any issue.
4. Test coverage is very well. It has all scenarios and all operators are
tested with line. That's
On Wed, Oct 2, 2013 at 6:12 AM, Peter Eisentraut pete...@gmx.net wrote:
On Wed, 2013-09-25 at 14:26 +0530, Jeevan Chalke wrote:
So no issues from my side.
However, do we still need this in close_pl() ?
#ifdef NOT_USED
if (FPeq(line-A, -1.0) FPzero(line-B
On Wed, Oct 9, 2013 at 10:44 AM, Peter Eisentraut pete...@gmx.net wrote:
On Thu, 2013-10-03 at 17:50 +0530, Jeevan Chalke wrote:
Will you please attach new patch with above block removed ? Then I
will quickly check that new patch and mark as Ready For Committer.
Here you go.
Thanks
Hi Oskari,
I had a quick look over the patch (Not compiled though). Here are few
comments on the changes:
1. Documentation is missing and thus becomes difficult to understand what
exactly you are trying to do. Or in other words, user will be uncertain
about
using it more efficiently.
2. Some
On Mon, Jan 13, 2014 at 4:30 PM, Oskari Saarenmaa o...@ohmu.fi wrote:
Hi,
On 13/01/14 10:26, Jeevan Chalke wrote:
1. Documentation is missing and thus becomes difficult to understand what
exactly you are trying to do. Or in other words, user will be uncertain
about using it more
On Thu, Oct 31, 2013 at 10:50 AM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
On Tue, Oct 29, 2013 at 11:05 PM, Robert Haas robertmh...@gmail.comwrote:
On Tue, Oct 29, 2013 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It turns out
Hi Pavel,
I have reviewed the patch and here are my concerns and notes:
POSITIVES:
---
1. Patch applies with some white-space errors.
2. make / make install / make check is smooth. No issues as such.
3. Feature looks good as well.
4. NO concern on overall design.
5. Good work.
NEGATIVES:
---
Hi Oskari,
Patch looks good to me now. I have found no issues too. It is good to go in
now.
However, few small suggestions:
1. Whenever we know that a variable is containing only 32 bits, better
define
it as uint32 and not just int (m_sqlstate in get_sqlstate_error_level()
function). int size
I went to review this, and found that there's not actually a patch
attached ...
regards, tom lane
Attached. Sorry for that.
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
diff --git
.
*/
Or as per your choice.
Need to have careful thought on a bug mentioned above.
Thanks
On Fri, Jan 17, 2014 at 6:23 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
2014/1/16 Jeevan Chalke jeevan.cha...@enterprisedb.com
Hi Pavel,
I have reviewed the patch and here
Hi Pavel,
Now the patch looks good to me. However when I try to restore your own sql
file's dump, I get following errors:
pg_restore: [archiver (db)] could not execute query: ERROR: relation
public.emp does not exist
Command was: DROP TRIGGER IF EXISTS emp_insert_trigger ON public.emp;
Hi Pavel,
it should be fixed by
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b152c6cd0de1827ba58756e24e18110cf902182acommit
Ok. Good.
Sorry I didn't update my sources. Done now. Thanks
Also, I didn't quite understand these lines of comments:
Hi Oskari,
Are you planning to work on what Tom has suggested ? It make sense to me as
well.
What are your views on that ?
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Hi Pavel,
Now patch looks good to me and I think it is in good shape to pass it on to
the committer as well.
However, I have
- Tweaked few comments
- Removed white-space errors
- Fixed typos
- Fixed indentation
Attached patch with my changes. However entire design and code logic is
untouched.
OK.
Assigned it to committer.
Thanks for the hard work.
On Thu, Jan 30, 2014 at 6:16 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
All is ok
Thank you
Pavel
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL
,
but still you got unstable build. NOT sure how. Seems like you are applying
wrong patch.
Will you please let us know what's going wrong ?
Thanks
On Thu, Jan 30, 2014 at 6:56 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
2014-01-30 Jeevan Chalke jeevan.cha...@enterprisedb.com:
OK
On Mon, Feb 17, 2014 at 7:43 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote:
Jeevan Chalke escribió:
If yes, then in my latest attached patch, these lines are NOT AT ALL
there.
I have informed on my comment that I have fixed these in my version of
patch,
but still you got unstable
On Tue, Mar 4, 2014 at 11:28 AM, Wang, Jing ji...@fast.au.fujitsu.com
wrote:
I don't buy your argument. Why isn't verbose option sufficient? Did you
read the old thread about this [1]?
[1] http://www.postgresql.org/message-id/3677.1253912...@sss.pgh.pa.us
AFAICS a lot of people compare
Hi Sawada Masahiko,
I liked this feature. So I have reviewed it.
Changes are straight forward and looks perfect.
No issues found with make/make install/initdb/regression.
However I would suggest removing un-necessary braces at if, as we have only
one statement into it.
if (++cur_line =
On Sun, Jun 29, 2014 at 4:18 PM, David Rowley dgrowle...@gmail.com wrote:
I think I'm finally ready for a review again, so I'll update the
commitfest app.
I have reviewed this on code level.
1. Patch gets applied cleanly.
2. make/make install/make check all are fine
No issues found till
at 7:17 PM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Hi Sawada Masahiko,
I liked this feature. So I have reviewed it.
Changes are straight forward and looks perfect.
No issues found with make/make install/initdb/regression.
However I would suggest removing un-necessary
Hi,
With further testing I noticed that the patch was not allowing ANTI joins
in cases like this:
explain select * from a where id not in(select x from b natural join c);
I too found this with natural joins and was about to report that. But its
good that you found that and fixed it as
Hi,
Found few more bugs in new code:
A:
This got bad:
jeevan@ubuntu:~/pg_master$ ./install/bin/psql postgres
psql (9.5devel)
Type help for help.
postgres=# \set PROMPT1 '%/[%l]%R%# '
postgres[1]=# \set PROMPT2 '%/[%l]%R%# '
postgres[1]=# select
postgres[2]-# *
postgres[3]-# from
postgres[4]-#
Hi,
Found new issues with latest patch:
Thank you for reviewing the patch with variable cases.
I have revised the patch, and attached latest patch.
A:
Will you please explain the idea behind these changes ?
I thought wrong about adding new to tail of query_buf.
The latest patch does
Hi,
On Fri, Jul 11, 2014 at 3:13 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
To my understating cleanly, you means that line number is not changed
when newline has reached to INT_MAX, is incorrect?
As per my thinking yes.
And the line number should be switched to 1 when line
Hi,
I have reviewed this:
I have initialize cur_lineno to UINTMAX - 2. And then observed following
behaviour to check wrap-around.
postgres=# \set PROMPT1 '%/[%l]%R%# '
postgres[18446744073709551613]=# \set PROMPT2 '%/[%l]%R%# '
postgres[18446744073709551613]=# select
Hi Pavel,
You have said that XMLFOREST has something which ignores nulls, what's that?
Will you please provide an example ?
I am NOT sure, but here you are trying to omit entire field from the output
when its value is NULL. But that will add an extra efforts at other end
which is using output of
I would like to ignore this as UINTMAX lines are too much for a input
buffer to hold. It is almost NIL chances to hit this.
Yeah, most likely you will run out of memory before reaching that point,
or out of patience.
Yep.
BTW, I have marked this as waiting for committer.
Thanks
--
Hi Pavel,
Patch does look good to me. And found no issues as such.
However here are my optional suggestions:
1. Frankly, I did not like name of the function row_to_json_pretty_choosy.
Something like row_to_json_pretty_ignore_nulls seems better to me.
2. To use ignore nulls feature, I have to
Hi Pavel,
it needs a redesign of original implementation, we should to change API to
use default values with named parameters
but it doesn't help too much (although it can be readable little bit more)
instead row_to_json(x, false, true)
be
row_ro_json(x, ignore_null := true)
it is not
Hi Pavel,
Here are few more comments on new implementation.
1.
/*
- * SQL function row_to_json(row)
+ * SQL function row_to_json(row record, pretty bool, ignore_nulls bool)
*/
In above comments, parameter name row should changed to rowval.
2.
-DATA(insert OID = 3155 ( row_to_json
Hi Pavel,
You have attached wrong patch.
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
On Thu, Sep 4, 2014 at 11:41 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am sory
too much patches
:)
Patch looks good to me.
Marking Ready for Committer.
Thanks
Regards
Pavel
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The
Hi,
Regarding Loading Custom Format Dump:
===
When we supply plain sql file to pg_restore, we get following error:
$ ./install/bin/pg_restore a.sql
pg_restore: [archiver] input file does not appear to be a valid archive
So I would expect similar kind of message when we provide non-plain sql
file
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Looks good. Passing it to committer.
The new status of this
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
Tom suggested few changes already which I too think author needs to
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
1.
+#include utils/acl.h
Can you please
The attatched are the fourth version of this patch.
0001-Add-regrole_v4.patch
0002-Add-regnamespace_v4.patch
Seems like you have missed to attach both the patches.
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Hi,
Personally, I was looking for something like this as I need to see rolename
and namespace name many times in my queries rather than it's oid.
But making a JOIN expression every-time was a pain. This certainly makes it
easier. And I see most DBAs are looking for it.
I agree on Tom's concern
Reviewed posted directly on mail thread instead of posting it on commitfest app.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I have reviewed the patch.
Patch is excellent in shape and
Álvaro,
I think, there are few open questions here and thus marking it back to Waiting
on Author.
Please have your views on the review comments already posted.
Also make changes as Tom suggested about placing pstate at the beginning.
I am more concerned about this:
1.
postgres=# create or
Hi,
I found some dead code in CREATE/RENAME ROLE code path.
Attached patch to remove those.
We have introduced RoleSpec and handled public and none role names in
grammar
itself. We do have these handling in CreateRole() and RenameRole() which is
NO more valid now.
Here is the related commit:
On Mon, Jun 8, 2015 at 8:19 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-08 14:44:53 +, Jeevan Chalke wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
This is trivial bug fix in the area of hiding error context.
Hi,
Attached patch which fixes my review comments.
Since code changes were good, just fixed reported cosmetic changes.
David, can you please cross check?
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
diff
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I have reviewed the patch.
Here are my review comments:
1.
Hi
Patch looks excellent now. No issues.
Found a typo which I have fixed in the attached patch.
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
diff --git a/doc/src/sgml/ref/psql-ref.sgml
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Patch looks good to pass to committer.
The new status of
Hi,
I have observed that we are not tab-completing word PASSWORD in the
following
syntaxes:
1.
CREATE|ALTER ROLE|USER rolname
2.
CREATE|ALTER ROLE|USER rolname WITH
PASSWORD is used many times and should be in the tab-complete list.
Was there any reason we have deliberately kept this out?
If
1 - 100 of 167 matches
Mail list logo
