Re: [COMMITTERS] pgsql: Logical replication

[Pavel Stehule]

2017-01-21 6:56 GMT+01:00 Amit Langote :

> On Sat, Jan 21, 2017 at 1:19 PM, Amit Kapila 
> wrote:
> > On Fri, Jan 20, 2017 at 7:36 PM, Peter Eisentraut 
> wrote:
> >> Logical replication
> >>
> >> - Add PUBLICATION catalogs and DDL
> >> - Add SUBSCRIPTION catalog and DDL
> >> - Define logical replication protocol and output plugin
> >> - Add logical replication workers
> >>
> >> From: Petr Jelinek 
> >> Reviewed-by: Steve Singer 
> >> Reviewed-by: Andres Freund 
> >> Reviewed-by: Erik Rijkers 
> >> Reviewed-by: Peter Eisentraut 
> >>
> >>
> > ..
> >> 119 files changed, 13354 insertions(+), 95 deletions(-)
> >>
> >
> >
> > Great work, Congrats Peter Jelinek and Thanks to all involved.
> > Getting a feature of this magnitude deserves a big round of applause.
>
> +1, congrats!
>

+1 pretty big work is done!

Pavel

>
> Thanks,
> Amit
>
>
> --
> Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-committers
>

Re: [COMMITTERS] pgsql: Simplify LWLock tranche machinery by removing array_base/array_s

[Pavel Stehule]

Hi

Is there some help for extensions developers, how to fix extensions after
this change?

Orafce hits this change.

Regards

Pavel

2016-12-16 17:41 GMT+01:00 Robert Haas :

> Simplify LWLock tranche machinery by removing array_base/array_stride.
>
> array_base and array_stride were added so that we could identify the
> offset of an LWLock within a tranche, but this facility is only very
> marginally used apart from the main tranche.  So, give every lock in
> the main tranche its own tranche ID and get rid of array_base,
> array_stride, and all that's attached.  For debugging facilities
> (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the
> LWLock using %p instead of the offset.  This is arguably more useful,
> and certainly a lot cheaper.  Drop the offset-within-tranche from
> the information reported to dtrace and from one can't-happen message
> inside lwlock.c.
>
> The main user-visible impact of this change is that pg_stat_activity
> will now report all waits for LWLocks as "LWLock" rather than
> reporting some as "LWLockTranche" and others as "LWLockNamed".
>
> The main motivation for this change is that the need to specify an
> array_base and an array_stride is awkward for parallel query.  There
> is only a very limited supply of tranche IDs so we can't just keep
> allocating new ones, and if we try to use the same tranche IDs every
> time then we run into trouble when multiple parallel contexts are
> use simultaneously.  So if we didn't get rid of this mechanism we'd
> have to make it even more complicated.  By simplifying it in this
> way, we instead reduce the size of the generated code for lwlock.c
> by about 5%.
>
> Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4
> djtcn47_q6d0sp8...@mail.gmail.com
>
> Branch
> --
> master
>
> Details
> ---
> http://git.postgresql.org/pg/commitdiff/3761fe3c20bb040b15f0e8da58d824
> 631da00caa
>
> Modified Files
> --
> doc/src/sgml/monitoring.sgml |  52 -
> src/backend/access/transam/slru.c|   6 +-
> src/backend/access/transam/xlog.c|   9 +-
> src/backend/postmaster/pgstat.c  |  10 +-
> src/backend/replication/logical/origin.c |   8 +-
> src/backend/replication/slot.c   |   8 +-
> src/backend/storage/buffer/buf_init.c|  16 +--
> src/backend/storage/ipc/procarray.c  |   9 +-
> src/backend/storage/lmgr/lwlock.c| 175
> ++-
> src/backend/utils/mmgr/dsa.c |  15 +--
> src/backend/utils/probes.d   |  16 +--
> src/include/access/slru.h|   1 -
> src/include/pgstat.h |   3 +-
> src/include/storage/lwlock.h |  45 ++--
> 14 files changed, 112 insertions(+), 261 deletions(-)
>
>
> --
> Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-committers
>

Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

[Pavel Stehule]

Hi

2016-03-10 19:55 GMT+01:00 Robert Haas :

> Provide much better wait information in pg_stat_activity.
>
> When a process is waiting for a heavyweight lock, we will now indicate
> the type of heavyweight lock for which it is waiting.  Also, you can
> now see when a process is waiting for a lightweight lock - in which
> case we will indicate the individual lock name or the tranche, as
> appropriate - or for a buffer pin.
>
> Amit Kapila, Ildus Kurbangaliev, reviewed by me.  Lots of helpful
> discussion and suggestions by many others, including Alexander
> Korotkov, Vladimir Borodin, and many others.
>
> Branch
> --
> master
>
>
I am trying to test this feature, and there I see not actual data. Maybe
this behave is not related to this patch:

create table foo(a int);
insert into foo values(10);

session one:

begin; select * from foo for update;

session two:

begin; select * from foo for update;
session two is waiting

session one:
select * from pg_stat_activity -- I don't see correct information about
session two

session two:
rollback; begin; select * from foo where a = 10 for update;
session two is waiting again

session one:
select * from pg_stat_activity; -- The content is not changed

So content of pg_stat_activity is not correct in holder lock session.
Independent third session see valid content of pg_stat_activity.

Hypothesis: the pg_stat_activity is not refreshed under opened transaction?

Regards

Pavel

Re: [COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

[Pavel Stehule]

2016-02-20 11:07 GMT+01:00 Dean Rasheed <dean.a.rash...@gmail.com>:

> Add pg_size_bytes() to parse human-readable size strings.
>
> This will parse strings in the format produced by pg_size_pretty() and
> return sizes in bytes. This allows queries to be written with clauses
> like "pg_total_relation_size(oid) > pg_size_bytes('10 GB')".
>
> Author: Pavel Stehule with various improvements by Vitaly Burovoy
> Discussion:
> http://www.postgresql.org/message-id/cafj8prd-tgodknxdygecza4on01_urqprwf-8ldkse-6bdh...@mail.gmail.com
> Reviewed-by: Vitaly Burovoy, Oleksandr Shulgin, Kyotaro Horiguchi,
> Michael Paquier and Robert Haas
>
> Branch
> --
> master
>
> Details
> ---
>
> http://git.postgresql.org/pg/commitdiff/53874c5228fe16589a4d01b3e1fab3678e0fd8e3
>
> Modified Files
> --
> doc/src/sgml/func.sgml   |  32 +++-
> src/backend/utils/adt/dbsize.c   | 149
> +++
> src/include/catalog/catversion.h |   2 +-
> src/include/catalog/pg_proc.h|   2 +
> src/include/utils/builtins.h |   1 +
> src/test/regress/expected/dbsize.out | 109 +
> src/test/regress/sql/dbsize.sql  |  39 +
> 7 files changed, 331 insertions(+), 3 deletions(-)
>

great :)

Thank you very much

Regards

Pavel


>
>
> --
> Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-committers
>

Re: [COMMITTERS] pgsql: Code and docs review for multiple -c and -f options in psql.

[Pavel Stehule]

2015-12-14 3:16 GMT+01:00 Michael Paquier :

> On Mon, Dec 14, 2015 at 11:16 AM, Michael Paquier wrote:
> > -   cell = (SimpleActionListCell *)
> > -   pg_malloc(offsetof(SimpleActionListCell, val) + vallen + 1);
> > Thanks! Among all those things this bit is a bit shameful..
>
> (I am the one at the origin of that FWIW)
>

me too

Thank you

Pavel


> --
> Michael
>
>
> --
> Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-committers
>

Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension

[Pavel Stehule]

2015-05-15 12:14 GMT+02:00 Thom Brown t...@linux.com:

 On 15 May 2015 at 10:56, Pavel Stehule pavel.steh...@gmail.com wrote:
  Hi
 
  I am testing it, and output is strange
 
  2015-05-15 11:49:25.046 CEST pavel postgres: LOG:  AUDIT:
  SESSION,1,1,DDL,DROP TABLE,,,drop table foo;,not logged
  2015-05-15 11:49:25.046 CEST pavel postgres: STATEMENT:  drop table foo;
  2015-05-15 11:49:28.291 CEST pavel postgres: LOG:  AUDIT:
  SESSION,2,1,DDL,CREATE TABLE,,,CREATE TABLE foo(a int, b int);,not
  logged
  2015-05-15 11:49:28.291 CEST pavel postgres: STATEMENT:  CREATE TABLE
 foo(a
  int, b int);
  2015-05-15 11:49:31.486 CEST pavel postgres: LOG:  AUDIT:
  SESSION,3,1,WRITE,INSERT,,,INSERT INTO foo VALUES(10,20);,not logged
  2015-05-15 11:49:31.486 CEST pavel postgres: STATEMENT:  INSERT INTO foo
  VALUES(10,20);
  2015-05-15 11:49:33.446 CEST pavel postgres: LOG:  AUDIT:
  SESSION,4,1,READ,SELECT,,,SELECT * FROM foo WHERE a = 10;,not logged
  2015-05-15 11:49:33.446 CEST pavel postgres: STATEMENT:  SELECT * FROM
 foo
  WHERE a = 10;
 
  I am missing object name, unexpected string not logged
 
  configuration:
  pg_audit.log = 'read, write, ddl'

 From what I can tell, that last value should be for parameters.  You'd
 need to set pg_audit.log_parameter to on, and then prepare and execute
 a statement with a parameter.


yes

2015-05-15 12:18:39.545 CEST pavel postgres: LOG:  AUDIT:
SESSION,1,1,READ,PREPARE,,,prepare x(int) as select * from foo where a =
$1;,none
2015-05-15 12:18:39.545 CEST pavel postgres: STATEMENT:  prepare x(int) as
select * from foo where a = $1;
2015-05-15 12:18:48.065 CEST pavel postgres: LOG:  AUDIT:
SESSION,2,1,READ,SELECT,,,prepare x(int) as select * from foo where a =
$1;,10
2015-05-15 12:18:48.065 CEST pavel postgres: STATEMENT:  execute x(10);

but when pg_audit.log_parameter is off, then this value should be empty

Regards

Pavel



 --
 Thom

Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension

[Pavel Stehule]

Hi

I am testing it, and output is strange

2015-05-15 11:49:25.046 CEST pavel postgres: LOG:  AUDIT:
SESSION,1,1,DDL,DROP TABLE,,,drop table foo;,not logged
2015-05-15 11:49:25.046 CEST pavel postgres: STATEMENT:  drop table foo;
2015-05-15 11:49:28.291 CEST pavel postgres: LOG:  AUDIT:
SESSION,2,1,DDL,CREATE TABLE,,,CREATE TABLE foo(a int, b int);,not
logged
2015-05-15 11:49:28.291 CEST pavel postgres: STATEMENT:  CREATE TABLE foo(a
int, b int);
2015-05-15 11:49:31.486 CEST pavel postgres: LOG:  AUDIT:
SESSION,3,1,WRITE,INSERT,,,INSERT INTO foo VALUES(10,20);,not logged
2015-05-15 11:49:31.486 CEST pavel postgres: STATEMENT:  INSERT INTO foo
VALUES(10,20);
2015-05-15 11:49:33.446 CEST pavel postgres: LOG:  AUDIT:
SESSION,4,1,READ,SELECT,,,SELECT * FROM foo WHERE a = 10;,not logged
2015-05-15 11:49:33.446 CEST pavel postgres: STATEMENT:  SELECT * FROM foo
WHERE a = 10;

I am missing object name, unexpected string not logged

configuration:
pg_audit.log = 'read, write, ddl'



2015-05-14 21:30 GMT+02:00 Stephen Frost sfr...@snowman.net:

 * Stephen Frost (sfr...@snowman.net) wrote:
  I'll continue to think about it though, perhaps there's a way I can
  disable logging as the superuser without it logging the role involved.

 Of course, it occured to me how to address this immediately after, even
 though it hadn't in the hour or so prior.  I can just bump
 client_min_messages up to warning and then reset the role attributes...

 That appears to be working.  Will push an update to fix this shortly.

 Thanks!

 Stephen

Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension

[Pavel Stehule]

2015-05-15 12:37 GMT+02:00 Thom Brown t...@linux.com:

 On 15 May 2015 at 11:20, Pavel Stehule pavel.steh...@gmail.com wrote:
 
 
  2015-05-15 12:14 GMT+02:00 Thom Brown t...@linux.com:
 
  On 15 May 2015 at 10:56, Pavel Stehule pavel.steh...@gmail.com wrote:
   Hi
  
   I am testing it, and output is strange
  
   2015-05-15 11:49:25.046 CEST pavel postgres: LOG:  AUDIT:
   SESSION,1,1,DDL,DROP TABLE,,,drop table foo;,not logged
   2015-05-15 11:49:25.046 CEST pavel postgres: STATEMENT:  drop table
 foo;
   2015-05-15 11:49:28.291 CEST pavel postgres: LOG:  AUDIT:
   SESSION,2,1,DDL,CREATE TABLE,,,CREATE TABLE foo(a int, b int);,not
   logged
   2015-05-15 11:49:28.291 CEST pavel postgres: STATEMENT:  CREATE TABLE
   foo(a
   int, b int);
   2015-05-15 11:49:31.486 CEST pavel postgres: LOG:  AUDIT:
   SESSION,3,1,WRITE,INSERT,,,INSERT INTO foo VALUES(10,20);,not
 logged
   2015-05-15 11:49:31.486 CEST pavel postgres: STATEMENT:  INSERT INTO
 foo
   VALUES(10,20);
   2015-05-15 11:49:33.446 CEST pavel postgres: LOG:  AUDIT:
   SESSION,4,1,READ,SELECT,,,SELECT * FROM foo WHERE a = 10;,not logged
   2015-05-15 11:49:33.446 CEST pavel postgres: STATEMENT:  SELECT * FROM
   foo
   WHERE a = 10;
  
   I am missing object name, unexpected string not logged
  
   configuration:
   pg_audit.log = 'read, write, ddl'
 
  From what I can tell, that last value should be for parameters.  You'd
  need to set pg_audit.log_parameter to on, and then prepare and execute
  a statement with a parameter.
 
 
  yes
 
  2015-05-15 12:18:39.545 CEST pavel postgres: LOG:  AUDIT:
  SESSION,1,1,READ,PREPARE,,,prepare x(int) as select * from foo where a =
  $1;,none
  2015-05-15 12:18:39.545 CEST pavel postgres: STATEMENT:  prepare x(int)
 as
  select * from foo where a = $1;
  2015-05-15 12:18:48.065 CEST pavel postgres: LOG:  AUDIT:
  SESSION,2,1,READ,SELECT,,,prepare x(int) as select * from foo where a =
  $1;,10
  2015-05-15 12:18:48.065 CEST pavel postgres: STATEMENT:  execute x(10);
 
  but when pg_audit.log_parameter is off, then this value should be empty

 If it were empty, it would then be indistinguishable from a statement
 executed with a single parameter passed as an empty string.


I am thinking about situation when pg_audit.log_parameter is disabled



 Speaking of which, I notice that nulls show up as nothing too.  How
 does one distinguish between an empty string and a null in the logs?


it can use a COPY notation



 --
 Thom

Re: [COMMITTERS] pgsql: Additional functions and operators for jsonb

[Pavel Stehule]

Hi

I did some tests, and I am not sure if this is not bug:

postgres=# select '{x:20}'::jsonb - 'x'::text;
ERROR:  unknown type of jsonb container --- it should be empty jsonb,
not error
Time: 0.971 ms
postgres=# select '{x:20, y:30}'::jsonb - 'x'::text;
┌───┐
│ ?column?  │
╞═══╡
│ {y: 30} │
└───┘
(1 row)


Regards

Pavel

2015-05-12 21:55 GMT+02:00 Andrew Dunstan and...@dunslane.net:

 Additional functions and operators for jsonb

 jsonb_pretty(jsonb) produces nicely indented json output.
 jsonb || jsonb concatenates two jsonb values.
 jsonb - text removes a key and its associated value from the json
 jsonb - int removes the designated array element
 jsonb - text[] removes a key and associated value or array element at
 the designated path
 jsonb_replace(jsonb,text[],jsonb) replaces the array element designated
 by the path or the value associated with the key designated by the path
 with the given value.

 Original work by Dmitry Dolgov, adapted and reworked for PostgreSQL core
 by Andrew Dunstan, reviewed and tidied up by Petr Jelinek.

 Branch
 --
 master

 Details
 ---

 http://git.postgresql.org/pg/commitdiff/c6947010ceb42143d9f047c65c1eac2b38928ab7

 Modified Files
 --
 doc/src/sgml/func.sgml|   62 +++
 src/backend/utils/adt/jsonb.c |   81 +++-
 src/backend/utils/adt/jsonfuncs.c |  717
 +
 src/include/catalog/pg_operator.h |8 +
 src/include/catalog/pg_proc.h |9 +-
 src/include/utils/jsonb.h |   19 +-
 src/test/regress/expected/jsonb.out   |  424 ++-
 src/test/regress/expected/jsonb_1.out |  424 ++-
 src/test/regress/sql/jsonb.sql|   85 +++-
 9 files changed, 1813 insertions(+), 16 deletions(-)


 --
 Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add new psql help topics, accessible to both --help and \?.

[Pavel Stehule]

2014-09-10 3:04 GMT+02:00 Andres Freund and...@anarazel.de:

 On 2014-09-09 22:12:35 +, Andres Freund wrote:
  Add new psql help topics, accessible to both --help and \?.
 
  Add --help=topic for the commandline, and \? topic as a backslash
  command, to show more help than the invocations without parameters
  do. commands, variables and options currently exist as help
  topics describing, respectively, backslash commands, psql variables,
  and commandline switches. Without parameters the help commands show
  their previous topic.
 
  Some further wordsmithing or extending of the added help content might
  be needed; but there seems little benefit delaying the overall feature
  further.
 
  Author: Pavel Stehule, editorialized by many
 
  Reviewed-By: Andres Freund, Petr Jelinek, Fujii Masao, MauMau, Abhijit
  Menon-Sen and Erik Rijkers.
 
  Discussion: CAFj8pRDVGuC-nXBfe2CK8vpyzd2Dsr9GVpbrATAnZO=
 2yq0...@mail.gmail.com,
  cafj8pra54abtv2rxdtrxiad8hy8wxmovlqhjdrcwenhdd7o...@mail.gmail.com

 Hm. This fails on windows right now because the getopt_long() fallback
 implementation doesn't implement optional_argument. Unless people think
 this can be broken for a day or somebody has a better solution, I'll
 revert tomorrow morning.
 The best plan after that seems to be to add optional_argument support to
 getopt_long.c - looks easy enough.


+1

Pavel


 Do we need a configure test for
 optional_argument? I don't think so, but I could see somebody arguing
 the other way round.

 Greetings,

 Andres Freund

 --
  Andres Freund http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training  Services


 --
 Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL

[Pavel Stehule]

Hello

2013/7/25 Tom Lane t...@sss.pgh.pa.us:
 Stephen Frost sfr...@snowman.net writes:
 I've just pushed up some much needed improvements to the comments which
 hopefully clarify that this function is using error_context_stack and
 calling the callbacks set up there by callers above on the PG call
 stack.

 Now that I'm a bit more awake, I realize that my comments last night
 were off-target.  As you say, the purpose of this function is to extract
 the context information that's been stacked against the possibility of a
 future error, so it's unrelated to actual error processing, and the
 FlushErrorState call is *not* destroying its input data as I claimed.

 Also, hopefully this makes it clear that errrordata is required
 to be empty when this function is called and therefore it can be cleaned
 up when exiting with FlushErrorState.

 But having said that, unrelated does not mean cannot be used together
 with.  I think this implementation of the function is dangerous (PANIC?
 really?), overly restrictive, and overcomplicated to boot.  The only
 reason you need to call FlushErrorState is to get rid of any palloc's
 leaked by errcontext functions, and the only reason that that's even
 of concern is that you're allocating them in ErrorContext which is a
 precious resource.  I don't think this function has any business
 touching ErrorContext at all, precisely because it isn't part of error
 recovery.  Indeed, by eating up reserved ErrorContext space, you
 increase the risk of an error within this function being unrecoverable.
 Saner would be either:

 1. Just run the whole business in the caller's context and leave it up
 to the caller to worry about whether it needs to clean up memory usage.

 2. Create a temporary context underneath CurrentMemoryContext, use that,
 and then delete it when done.

 The only thing that needs to be considered an error condition is if the
 errordata stack is too full to allow creation of the extra entry needed
 by this function, which is an improbable situation.  Other than
 temporarily stacking and then unstacking that entry, you don't need to
 have any side-effects on the state of the error subsystem.

 I'm happy to rework this or even revert it if this use of the
 error_context_stack is just too grotty, but this certainly looks like a
 useful capability to have.

 I'm not objecting to the functionality, just to the implementation:
 I think you could decouple this from error handling a lot better.

 One other minor gripe is that the function is documented as returning
 the call stack, which a C programmer would think means something
 entirely different from what is actually output.  I think you need to
 use a different phrase there.  error context stack would be OK.

I used a ErrorContext because I wasn't sure so errcontext and similar
function can work in different context. Now I look there and there
should be well initialized ErrorDataStack, due

int
set_errcontext_domain(const char *domain)
{
--ErrorData  *edata = errordata[errordata_stack_depth];

--/* we don't bother incrementing recursion_depth */
--CHECK_STACK_DEPTH();

--edata-context_domain = domain;

--return 0;
}

but MemoryContext can be any - so probably some private context is ideal.

Regards

Pavel


 regards, tom lane


 --
 Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-committers


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL

[Pavel Stehule]

2013/7/25 Stephen Frost sfr...@snowman.net:
 Pavel,

 First, please only quote the relevant parts of the email when
 responding.

 * Pavel Stehule (pavel.steh...@gmail.com) wrote:
 I used a ErrorContext because I wasn't sure so errcontext and similar
 function can work in different context. Now I look there and there
 should be well initialized ErrorDataStack, due

 int
 set_errcontext_domain(const char *domain)
 {
 --ErrorData  *edata = errordata[errordata_stack_depth];

 --/* we don't bother incrementing recursion_depth */
 --CHECK_STACK_DEPTH();

 --edata-context_domain = domain;

 --return 0;
 }

 but MemoryContext can be any - so probably some private context is ideal.

 While set_errcontext_domain() doesn't care about the MemoryContext, per
 se, the errcontext() macro further calls errcontext_msg() which is
 currently set up to explicitly use ErrorContext.  Perhaps an elog.c
 global to tell errcontext_msg() to not switch memory contexts, but what
 happens if there's an error thrown by a callback function..?

Probably then will be raised a panic due recursion call of error API

Our PL doesn't raise a exception in callback function explicitly.
Probably there is risk - out of memory - but same risk is when you
call errcontext inside elog function.

Pavel


 Thanks,

 Stephen


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Improve pretty printing of viewdefs.

[Pavel Stehule]

Hello

nice

should be this functionality used for query too?

some like

pg_pretty_query('SELECT ... ', 80)

when we have this functionality.

Regards

Pavel

2012/2/19 Andrew Dunstan and...@dunslane.net:
 Improve pretty printing of viewdefs.

 Some line feeds are added to target lists and from lists to make
 them more readable. By default they wrap at 80 columns if possible,
 but the wrap column is also selectable - if 0 it wraps after every
 item.

 Andrew Dunstan, reviewed by Hitoshi Harada.

 Branch
 --
 master

 Details
 ---
 http://git.postgresql.org/pg/commitdiff/2f582f76b1945929ff07116cd4639747ce9bb8a1

 Modified Files
 --
 doc/src/sgml/func.sgml                     |   12 ++-
 src/backend/utils/adt/ruleutils.c          |  137 +++-
 src/include/catalog/catversion.h           |    2 +-
 src/include/catalog/pg_proc.h              |    2 +
 src/include/utils/builtins.h               |    1 +
 src/test/regress/expected/polymorphism.out |    4 +-
 src/test/regress/expected/rules.out        |   33 +++
 src/test/regress/expected/with.out         |   25 +++---
 src/test/regress/sql/rules.sql             |    6 +
 9 files changed, 204 insertions(+), 18 deletions(-)


 --
 Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-committers

-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add string functions: concat(), concat_ws(), left(), right(), and

[Pavel Stehule]

Hello

documentation for left / right (negative parameters) maybe missing a
word without (without first/last n chars). Maybe not - I am not
native speaker.

Regards

Pavel

2010/8/24 Takahiro Itagaki itag...@postgresql.org:
 Log Message:
 ---
 Add string functions: concat(), concat_ws(), left(), right(), and reverse().

 Pavel Stehule, reviewed by me.

 Modified Files:
 --
    pgsql/doc/src/sgml:
        func.sgml (r1.529 - r1.530)
        
 (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/func.sgml?r1=1.529r2=1.530)
    pgsql/src/backend/utils/adt:
        varlena.c (r1.179 - r1.180)
        
 (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/varlena.c?r1=1.179r2=1.180)
    pgsql/src/include/catalog:
        catversion.h (r1.596 - r1.597)
        
 (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h?r1=1.596r2=1.597)
        pg_proc.h (r1.580 - r1.581)
        
 (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_proc.h?r1=1.580r2=1.581)
    pgsql/src/include/utils:
        builtins.h (r1.354 - r1.355)
        
 (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/builtins.h?r1=1.354r2=1.355)
    pgsql/src/test/regress/expected:
        text.out (r1.4 - r1.5)
        
 (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/text.out?r1=1.4r2=1.5)
    pgsql/src/test/regress/sql:
        text.sql (r1.4 - r1.5)
        
 (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/text.sql?r1=1.4r2=1.5)

 --
 Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-committers


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add BETWEEN SYMMETRIC.

[Pavel Stehule]

I'll correct it

Pavel Stehule

On Wed, 15 Jun 2005, Tom Lane wrote:

 [EMAIL PROTECTED] (Bruce Momjian) writes:
  Add BETWEEN SYMMETRIC.
 
 $ make
 bison -y -d  gram.y
 conflicts: 4 shift/reduce
 
 This is absolutely unacceptable.
 
   regards, tom lane
 


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [COMMITTERS] pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support

[Pavel Stehule]

On Thu, 2 Jun 2005, Tom Lane wrote:

 Neil Conway [EMAIL PROTECTED] writes:
  I should have commented on this earlier: I don't think exact Oracle 
  compatibility is _at all_ important.
 
 The results of Pavel's experiments prove that Oracle's behavior is
 pretty random --- it looks to me like the chance results of whatever

What I can speek. Oracle has session variable for saving err code of last 
exception. On the start of session is zero. After executing any EXCEPTION 
BLOCK is this session zeroed. I can't to see so it's buggy behavior. 

We have more possibilities, because wont to implement it only for PL/pgSQL 
and can do more complicated solutions. Maybe on general level, Oracle's 
developers had to use only solution on session variable.

 quick-and-dirty implementation someone chose long ago, rather than
 behavior that was thought out and agreed to.  I concur that we shouldn't
 feel a compulsion to match it exactly, especially seeing that we

true. Compatibility isn't tabu, but sometimes is very usefull ;-), and 
motivation for future.

 aren't going to match it exactly in terms of the contents of the
 variables, let alone fine details of what they may contain at different
 times.
 

Pavel


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [COMMITTERS] pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support

[Pavel Stehule]

On Thu, 2 Jun 2005, Tom Lane wrote:

 Pavel Stehule [EMAIL PROTECTED] writes:
  I din't find easy way how append variable only when block contains 
  EXCEPTION part. I wilcome any advice
 
 I was envisioning an action in the beginning of the EXCEPTION clause,
 viz
 
 exception_sect  :
 { $$ = NIL; }
 | K_EXCEPTION
 { push vars into namespace here }
   proc_exceptions
 { $$ = $2; }
 ;

True. It's can work. I'll change it.

Pavel Stehule


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [COMMITTERS] pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support

[Pavel Stehule]

On Thu, 26 May 2005, Neil Conway wrote:

 Tom Lane wrote:
  Alternatively we could make them local to any block that contains an
  EXCEPTION clause, which would fix point 3 and also go a long way towards
  addressing the unnecessary-overhead gripe.  However that would mean that
  an attempt to reference them from outside an exception handler would
  probably fail outright, rather than deliver either NULLs or
  0/Successful completion.
 
 This behavior sounds fine to me.
 
true, there is not any reason use this variables outside exception 
handler.

Pavel


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [COMMITTERS] pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support

[Pavel Stehule]

 
 That might be taking the notion of bug-compatibility with PL/SQL
 a bit too far.  For that matter, did you check whether Oracle
 actually treats it as a procedure-scope variable?  Try having the
 exception block call another function and trap an error inside that.
 Does SQLCODE change in the calling function?
 

good shot. Its more like session (global) variable.

create function foo2
return integer   
as   
begin   
  dbms_output.put_line('10: '||SQLCODE||' - '||SQLERRM);  
  raise_application_error(-20003, 'Third exception');   
end;

change of foo

   dbms_output.put_line('3: '||SQLCODE||' - '||SQLERRM);  
   --raise_application_error(-20002, 'Second exception');  
   f := foo2; 
  exception when others then  
  dbms_output.put_line('4: '||SQLCODE||' - '||SQLERRM);  
  end;  

and result:

1: 0 - ORA-: normal, successful completion
2: -20001 - ORA-20001: First exception
3: -20001 - ORA-20001: First exception
10: -20001 - ORA-20001: First exception
4: -20003 - ORA-20003: Third exception
5: 0 - ORA-: normal, successful completion
6: 0 - ORA-: normal, successful completion

foo2 knows first exception. Is it bug? Maybe. The exception was outside 
function, not in function and expected value of SQLCODE is zero.

Pavel


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [COMMITTERS] pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support

[Pavel Stehule]

   BEGIN
   -- do something perilous
   EXCEPTION
   WHEN OTHERS THEN -- nothing much
   END;
   IF SQLSTATE = '42000' THEN ...

I understand. My idea was detect local exception for local block, I can't 
to see exception's information outside block and I cant get exception's 
info from inner block. Your idea is easy for implementation, but oracle 

http://www.unix.org.ua/orelly/oracle/prog2/ch13_03.htm

In Oracle doc:

If no exception has been raised, SQLCODE returns zero and SQLERRM returns 
the message: ORA-: normal, successful completion.

If you reference SQLCODE outside of an exception section, it always 
returns 0, which means normal, successful completion.

I tested it on Oracle 10g

 return integer  as  
begin
  begin
dbms_output.put_line('1: '||SQLCODE||' - '||SQLERRM);
raise_application_error(-20001, 'First exception');
  exception when others then
dbms_output.put_line('2: '||SQLCODE||' - '||SQLERRM);
begin
  dbms_output.put_line('3: '||SQLCODE||' - '||SQLERRM);
  raise_application_error(-20002, 'Second exception');
exception when others then
  dbms_output.put_line('4: '||SQLCODE||' - '||SQLERRM);
end;
dbms_output.put_line('5: '||SQLCODE||' - '||SQLERRM);
  end;
  dbms_output.put_line('6: '||SQLCODE||' - '||SQLERRM);
  return 1;
end;

select foo from dual

1: 0 - ORA-: normal, successful completion
2: -20001 - ORA-20001: First exception
3: -20001 - ORA-20001: First exception
4: -20002 - ORA-20002: Second exception
5: 0 - ORA-: normal, successful completion
6: 0 - ORA-: normal, successful completion

What it is mean?

So we can have only one procedure level scope variable, which is 
initialized on start of exception and zeroized on the end of exception 
block. This behavior is different from my patch, but is better for Oracle 
compatibility and I prefere its.

I'll change patch, I can simplify it, if there will be agreement.

Best regards
Pavel Stehule



---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings