Thread

1. proposal: enable new error fields in plpgsql (9.4)

   Pavel Stehule <pavel.stehule@gmail.com> — 2013-02-01T12:47:41Z

   Hello
   
   now a most "hard" work is done and I would to enable access to new
   error fields from plpgsql.
   
   these new fields are column_name, constraint_name, datatype_name,
   table_name and schema_name.
   
   This proposal has impact on two plpgsql statements - RAISE and GET
   STACKED DIAGNOSTICS.
   
   I am sending initial implementation
   
   Comments, notes?
   
   Regards
   
   Pavel
   

2. Re: proposal: enable new error fields in plpgsql (9.4)

   Marko Tiikkaja <pgmail@joh.to> — 2013-02-01T12:52:23Z

   On 2/1/13 1:47 PM, Pavel Stehule wrote:
   > now a most "hard" work is done and I would to enable access to new
   > error fields from plpgsql.
   
   Is there a compelling reason why we wouldn't provide these already in 9.3?
   
   
   
   Regards,
   Marko Tiikkaja
   
   
   

3. Re: proposal: enable new error fields in plpgsql (9.4)

   Pavel Stehule <pavel.stehule@gmail.com> — 2013-02-01T13:00:30Z

   2013/2/1 Marko Tiikkaja <pgmail@joh.to>:
   > On 2/1/13 1:47 PM, Pavel Stehule wrote:
   >>
   >> now a most "hard" work is done and I would to enable access to new
   >> error fields from plpgsql.
   >
   >
   > Is there a compelling reason why we wouldn't provide these already in 9.3?
   
   a time for assign to last commitfest is out.
   
   this patch is relative simple and really close to enhanced error
   fields feature - but depends if some from commiters will have a time
   for commit to 9.3 - so I am expecting primary target 9.4, but I am not
   be angry if it will be commited early.
   
   Regards
   
   Pavel
   
   >
   >
   >
   > Regards,
   > Marko Tiikkaja
   
   
   

4. Re: proposal: enable new error fields in plpgsql (9.4)

   Peter Eisentraut <peter_e@gmx.net> — 2013-02-01T13:43:37Z

   On 2/1/13 8:00 AM, Pavel Stehule wrote:
   > 2013/2/1 Marko Tiikkaja <pgmail@joh.to>:
   >> On 2/1/13 1:47 PM, Pavel Stehule wrote:
   >>>
   >>> now a most "hard" work is done and I would to enable access to new
   >>> error fields from plpgsql.
   >>
   >>
   >> Is there a compelling reason why we wouldn't provide these already in 9.3?
   > 
   > a time for assign to last commitfest is out.
   > 
   > this patch is relative simple and really close to enhanced error
   > fields feature - but depends if some from commiters will have a time
   > for commit to 9.3 - so I am expecting primary target 9.4, but I am not
   > be angry if it will be commited early.
   
   If we don't have access to those fields on PL/pgSQL, what was the point
   of the patch to begin with?  Surely, accessing them from C wasn't the
   main use case?
   
   
   
   

5. Re: proposal: enable new error fields in plpgsql (9.4)

   Pavel Stehule <pavel.stehule@gmail.com> — 2013-02-01T13:51:32Z

   2013/2/1 Peter Eisentraut <peter_e@gmx.net>:
   > On 2/1/13 8:00 AM, Pavel Stehule wrote:
   >> 2013/2/1 Marko Tiikkaja <pgmail@joh.to>:
   >>> On 2/1/13 1:47 PM, Pavel Stehule wrote:
   >>>>
   >>>> now a most "hard" work is done and I would to enable access to new
   >>>> error fields from plpgsql.
   >>>
   >>>
   >>> Is there a compelling reason why we wouldn't provide these already in 9.3?
   >>
   >> a time for assign to last commitfest is out.
   >>
   >> this patch is relative simple and really close to enhanced error
   >> fields feature - but depends if some from commiters will have a time
   >> for commit to 9.3 - so I am expecting primary target 9.4, but I am not
   >> be angry if it will be commited early.
   >
   > If we don't have access to those fields on PL/pgSQL, what was the point
   > of the patch to begin with?  Surely, accessing them from C wasn't the
   > main use case?
   >
   
   These fields are available for application developers now. But is a
   true, so without this patch, GET STACKED DIAGNOSTICS statement will
   not be fully consistent, because some fields are accessible and others
   not
   
   Pavel
   
   
   

6. Re: proposal: enable new error fields in plpgsql (9.4)

   Pavel Stehule <pavel.stehule@gmail.com> — 2013-02-01T13:59:25Z

   2013/2/1 Pavel Stehule <pavel.stehule@gmail.com>:
   > 2013/2/1 Peter Eisentraut <peter_e@gmx.net>:
   >> On 2/1/13 8:00 AM, Pavel Stehule wrote:
   >>> 2013/2/1 Marko Tiikkaja <pgmail@joh.to>:
   >>>> On 2/1/13 1:47 PM, Pavel Stehule wrote:
   >>>>>
   >>>>> now a most "hard" work is done and I would to enable access to new
   >>>>> error fields from plpgsql.
   >>>>
   >>>>
   >>>> Is there a compelling reason why we wouldn't provide these already in 9.3?
   >>>
   >>> a time for assign to last commitfest is out.
   >>>
   >>> this patch is relative simple and really close to enhanced error
   >>> fields feature - but depends if some from commiters will have a time
   >>> for commit to 9.3 - so I am expecting primary target 9.4, but I am not
   >>> be angry if it will be commited early.
   >>
   >> If we don't have access to those fields on PL/pgSQL, what was the point
   >> of the patch to begin with?  Surely, accessing them from C wasn't the
   >> main use case?
   >>
   >
   > These fields are available for application developers now. But is a
   > true, so without this patch, GET STACKED DIAGNOSTICS statement will
   > not be fully consistent, because some fields are accessible and others
   > not
   
   there is one stronger argument for commit this patch now. With this
   patch, we are able to wrote regression tests for new fields via
   plpgsql.
   
   Regards
   
   Pavel
   
   >
   > Pavel
   
   
   

7. Re: proposal: enable new error fields in plpgsql (9.4)

   Rushabh Lathia <rushabh.lathia@gmail.com> — 2013-06-25T09:02:20Z

   Hi Pavel,
   
   I gone through the discussion over here and found that with this patch we
   enable the new error fields in plpgsql. Its a simple patch to expose the new
   error fields in plpgsql.
   
   Patch gets applied cleanly. make and make install too went smooth. make
   check
   was smooth too. Patch also include test coverage
   
   I tested the functionality with manual test and its woking as expected.
   
   BTW in the patch I found one additional new like in read_raise_options():
   
   @@ -3631,7 +3661,23 @@ read_raise_options(void)
                   else if (tok_is_keyword(tok, &yylval,
                                                                   K_HINT,
   "hint"))
                           opt->opt_type = PLPGSQL_RAISEOPTION_HINT;
   +               else if (tok_is_keyword(tok, &yylval,
   +
   K_COLUMN_NAME, "column_name"))
   +                       opt->opt_type = PLPGSQL_RAISEOPTION_COLUMN_NAME;
   +               else if (tok_is_keyword(tok, &yylval,
   +
   K_CONSTRAINT_NAME, "constraint_name"))
   +                       opt->opt_type = PLPGSQL_RAISEOPTION_CONSTRAINT_NAME;
   +               else if (tok_is_keyword(tok, &yylval,
   +
   K_DATATYPE_NAME, "datatype_name"))
   +                       opt->opt_type = PLPGSQL_RAISEOPTION_DATATYPE_NAME;
   +               else if (tok_is_keyword(tok, &yylval,
   +
   K_TABLE_NAME, "table_name"))
   +                       opt->opt_type = PLPGSQL_RAISEOPTION_TABLE_NAME;
   +               else if (tok_is_keyword(tok, &yylval,
   +
   K_SCHEMA_NAME, "schema_name"))
   +                       opt->opt_type = PLPGSQL_RAISEOPTION_SCHEMA_NAME;
                   else
   +
                           yyerror("unrecognized RAISE statement option");
   
   can you please remove that.
   
   Apart from that patch looks good to me.
   
   Thanks,
   Rushabh
   
   
   On Fri, Feb 1, 2013 at 7:29 PM, Pavel Stehule <pavel.stehule@gmail.com>wrote:
   
   > 2013/2/1 Pavel Stehule <pavel.stehule@gmail.com>:
   > > 2013/2/1 Peter Eisentraut <peter_e@gmx.net>:
   > >> On 2/1/13 8:00 AM, Pavel Stehule wrote:
   > >>> 2013/2/1 Marko Tiikkaja <pgmail@joh.to>:
   > >>>> On 2/1/13 1:47 PM, Pavel Stehule wrote:
   > >>>>>
   > >>>>> now a most "hard" work is done and I would to enable access to new
   > >>>>> error fields from plpgsql.
   > >>>>
   > >>>>
   > >>>> Is there a compelling reason why we wouldn't provide these already in
   > 9.3?
   > >>>
   > >>> a time for assign to last commitfest is out.
   > >>>
   > >>> this patch is relative simple and really close to enhanced error
   > >>> fields feature - but depends if some from commiters will have a time
   > >>> for commit to 9.3 - so I am expecting primary target 9.4, but I am not
   > >>> be angry if it will be commited early.
   > >>
   > >> If we don't have access to those fields on PL/pgSQL, what was the point
   > >> of the patch to begin with?  Surely, accessing them from C wasn't the
   > >> main use case?
   > >>
   > >
   > > These fields are available for application developers now. But is a
   > > true, so without this patch, GET STACKED DIAGNOSTICS statement will
   > > not be fully consistent, because some fields are accessible and others
   > > not
   >
   > there is one stronger argument for commit this patch now. With this
   > patch, we are able to wrote regression tests for new fields via
   > plpgsql.
   >
   > Regards
   >
   > Pavel
   >
   > >
   > > Pavel
   >
   >
   > --
   > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
   > To make changes to your subscription:
   > http://www.postgresql.org/mailpref/pgsql-hackers
   >
   
   
   
   -- 
   Rushabh Lathia
   

8. Re: proposal: enable new error fields in plpgsql (9.4)

   Pavel Stehule <pavel.stehule@gmail.com> — 2013-06-25T09:11:58Z

   2013/6/25 Rushabh Lathia <rushabh.lathia@gmail.com>:
   > Hi Pavel,
   >
   > I gone through the discussion over here and found that with this patch we
   > enable the new error fields in plpgsql. Its a simple patch to expose the new
   > error fields in plpgsql.
   >
   > Patch gets applied cleanly. make and make install too went smooth. make
   > check
   > was smooth too. Patch also include test coverage
   >
   > I tested the functionality with manual test and its woking as expected.
   >
   > BTW in the patch I found one additional new like in read_raise_options():
   >
   > @@ -3631,7 +3661,23 @@ read_raise_options(void)
   >                 else if (tok_is_keyword(tok, &yylval,
   >                                                                 K_HINT,
   > "hint"))
   >                         opt->opt_type = PLPGSQL_RAISEOPTION_HINT;
   > +               else if (tok_is_keyword(tok, &yylval,
   > +
   > K_COLUMN_NAME, "column_name"))
   > +                       opt->opt_type = PLPGSQL_RAISEOPTION_COLUMN_NAME;
   > +               else if (tok_is_keyword(tok, &yylval,
   > +
   > K_CONSTRAINT_NAME, "constraint_name"))
   > +                       opt->opt_type = PLPGSQL_RAISEOPTION_CONSTRAINT_NAME;
   > +               else if (tok_is_keyword(tok, &yylval,
   > +
   > K_DATATYPE_NAME, "datatype_name"))
   > +                       opt->opt_type = PLPGSQL_RAISEOPTION_DATATYPE_NAME;
   > +               else if (tok_is_keyword(tok, &yylval,
   > +
   > K_TABLE_NAME, "table_name"))
   > +                       opt->opt_type = PLPGSQL_RAISEOPTION_TABLE_NAME;
   > +               else if (tok_is_keyword(tok, &yylval,
   > +
   > K_SCHEMA_NAME, "schema_name"))
   > +                       opt->opt_type = PLPGSQL_RAISEOPTION_SCHEMA_NAME;
   >                 else
   > +
   >                         yyerror("unrecognized RAISE statement option");
   >
   > can you please remove that.
   
   No, these fields are there as was proposed - it enhance possibilities
   to PLpgSQL developers - they can use these fields for custom
   exceptions. It is same like possibility to specify SQLCODE, MESSAGE,
   HINT in current RAISE statement implementation.
   
   Why you dislike it?
   
   Regards
   
   Pavel
   
   >
   > Apart from that patch looks good to me.
   >
   > Thanks,
   > Rushabh
   >
   >
   > On Fri, Feb 1, 2013 at 7:29 PM, Pavel Stehule <pavel.stehule@gmail.com>
   > wrote:
   >>
   >> 2013/2/1 Pavel Stehule <pavel.stehule@gmail.com>:
   >> > 2013/2/1 Peter Eisentraut <peter_e@gmx.net>:
   >> >> On 2/1/13 8:00 AM, Pavel Stehule wrote:
   >> >>> 2013/2/1 Marko Tiikkaja <pgmail@joh.to>:
   >> >>>> On 2/1/13 1:47 PM, Pavel Stehule wrote:
   >> >>>>>
   >> >>>>> now a most "hard" work is done and I would to enable access to new
   >> >>>>> error fields from plpgsql.
   >> >>>>
   >> >>>>
   >> >>>> Is there a compelling reason why we wouldn't provide these already in
   >> >>>> 9.3?
   >> >>>
   >> >>> a time for assign to last commitfest is out.
   >> >>>
   >> >>> this patch is relative simple and really close to enhanced error
   >> >>> fields feature - but depends if some from commiters will have a time
   >> >>> for commit to 9.3 - so I am expecting primary target 9.4, but I am not
   >> >>> be angry if it will be commited early.
   >> >>
   >> >> If we don't have access to those fields on PL/pgSQL, what was the point
   >> >> of the patch to begin with?  Surely, accessing them from C wasn't the
   >> >> main use case?
   >> >>
   >> >
   >> > These fields are available for application developers now. But is a
   >> > true, so without this patch, GET STACKED DIAGNOSTICS statement will
   >> > not be fully consistent, because some fields are accessible and others
   >> > not
   >>
   >> there is one stronger argument for commit this patch now. With this
   >> patch, we are able to wrote regression tests for new fields via
   >> plpgsql.
   >>
   >> Regards
   >>
   >> Pavel
   >>
   >> >
   >> > Pavel
   >>
   >>
   >> --
   >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
   >> To make changes to your subscription:
   >> http://www.postgresql.org/mailpref/pgsql-hackers
   >
   >
   >
   >
   > --
   > Rushabh Lathia
   
   
   

9. Re: proposal: enable new error fields in plpgsql (9.4)

   Rushabh Lathia <rushabh.lathia@gmail.com> — 2013-06-25T09:24:05Z

   On Tue, Jun 25, 2013 at 2:41 PM, Pavel Stehule <pavel.stehule@gmail.com>wrote:
   
   > 2013/6/25 Rushabh Lathia <rushabh.lathia@gmail.com>:
   > > Hi Pavel,
   > >
   > > I gone through the discussion over here and found that with this patch we
   > > enable the new error fields in plpgsql. Its a simple patch to expose the
   > new
   > > error fields in plpgsql.
   > >
   > > Patch gets applied cleanly. make and make install too went smooth. make
   > > check
   > > was smooth too. Patch also include test coverage
   > >
   > > I tested the functionality with manual test and its woking as expected.
   > >
   > > BTW in the patch I found one additional new like in read_raise_options():
   > >
   > > @@ -3631,7 +3661,23 @@ read_raise_options(void)
   > >                 else if (tok_is_keyword(tok, &yylval,
   > >                                                                 K_HINT,
   > > "hint"))
   > >                         opt->opt_type = PLPGSQL_RAISEOPTION_HINT;
   > > +               else if (tok_is_keyword(tok, &yylval,
   > > +
   > > K_COLUMN_NAME, "column_name"))
   > > +                       opt->opt_type = PLPGSQL_RAISEOPTION_COLUMN_NAME;
   > > +               else if (tok_is_keyword(tok, &yylval,
   > > +
   > > K_CONSTRAINT_NAME, "constraint_name"))
   > > +                       opt->opt_type =
   > PLPGSQL_RAISEOPTION_CONSTRAINT_NAME;
   > > +               else if (tok_is_keyword(tok, &yylval,
   > > +
   > > K_DATATYPE_NAME, "datatype_name"))
   > > +                       opt->opt_type =
   > PLPGSQL_RAISEOPTION_DATATYPE_NAME;
   > > +               else if (tok_is_keyword(tok, &yylval,
   > > +
   > > K_TABLE_NAME, "table_name"))
   > > +                       opt->opt_type = PLPGSQL_RAISEOPTION_TABLE_NAME;
   > > +               else if (tok_is_keyword(tok, &yylval,
   > > +
   > > K_SCHEMA_NAME, "schema_name"))
   > > +                       opt->opt_type = PLPGSQL_RAISEOPTION_SCHEMA_NAME;
   > >                 else
   > > +
   > >                         yyerror("unrecognized RAISE statement option");
   > >
   > > can you please remove that.
   >
   > No, these fields are there as was proposed - it enhance possibilities
   > to PLpgSQL developers - they can use these fields for custom
   > exceptions. It is same like possibility to specify SQLCODE, MESSAGE,
   > HINT in current RAISE statement implementation.
   >
   > Why you dislike it?
   >
   
   Seems like some confusion.
   
   I noticed additional new line which has been added into your patch in
   function
   read_raise_options()::pl_gram.y @ line number 3680. And in the earlier mail
   thats what I asked to remove.
   
   
   
   
   > Regards
   >
   > Pavel
   >
   > >
   > > Apart from that patch looks good to me.
   > >
   > > Thanks,
   > > Rushabh
   > >
   > >
   > > On Fri, Feb 1, 2013 at 7:29 PM, Pavel Stehule <pavel.stehule@gmail.com>
   > > wrote:
   > >>
   > >> 2013/2/1 Pavel Stehule <pavel.stehule@gmail.com>:
   > >> > 2013/2/1 Peter Eisentraut <peter_e@gmx.net>:
   > >> >> On 2/1/13 8:00 AM, Pavel Stehule wrote:
   > >> >>> 2013/2/1 Marko Tiikkaja <pgmail@joh.to>:
   > >> >>>> On 2/1/13 1:47 PM, Pavel Stehule wrote:
   > >> >>>>>
   > >> >>>>> now a most "hard" work is done and I would to enable access to new
   > >> >>>>> error fields from plpgsql.
   > >> >>>>
   > >> >>>>
   > >> >>>> Is there a compelling reason why we wouldn't provide these already
   > in
   > >> >>>> 9.3?
   > >> >>>
   > >> >>> a time for assign to last commitfest is out.
   > >> >>>
   > >> >>> this patch is relative simple and really close to enhanced error
   > >> >>> fields feature - but depends if some from commiters will have a time
   > >> >>> for commit to 9.3 - so I am expecting primary target 9.4, but I am
   > not
   > >> >>> be angry if it will be commited early.
   > >> >>
   > >> >> If we don't have access to those fields on PL/pgSQL, what was the
   > point
   > >> >> of the patch to begin with?  Surely, accessing them from C wasn't the
   > >> >> main use case?
   > >> >>
   > >> >
   > >> > These fields are available for application developers now. But is a
   > >> > true, so without this patch, GET STACKED DIAGNOSTICS statement will
   > >> > not be fully consistent, because some fields are accessible and others
   > >> > not
   > >>
   > >> there is one stronger argument for commit this patch now. With this
   > >> patch, we are able to wrote regression tests for new fields via
   > >> plpgsql.
   > >>
   > >> Regards
   > >>
   > >> Pavel
   > >>
   > >> >
   > >> > Pavel
   > >>
   > >>
   > >> --
   > >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
   > >> To make changes to your subscription:
   > >> http://www.postgresql.org/mailpref/pgsql-hackers
   > >
   > >
   > >
   > >
   > > --
   > > Rushabh Lathia
   >
   
   
   
   -- 
   Rushabh Lathia
   

10. Re: proposal: enable new error fields in plpgsql (9.4)

    Pavel Stehule <pavel.stehule@gmail.com> — 2013-06-25T10:01:37Z

    2013/6/25 Rushabh Lathia <rushabh.lathia@gmail.com>:
    >
    >
    >
    > On Tue, Jun 25, 2013 at 2:41 PM, Pavel Stehule <pavel.stehule@gmail.com>
    > wrote:
    >>
    >> 2013/6/25 Rushabh Lathia <rushabh.lathia@gmail.com>:
    >> > Hi Pavel,
    >> >
    >> > I gone through the discussion over here and found that with this patch
    >> > we
    >> > enable the new error fields in plpgsql. Its a simple patch to expose the
    >> > new
    >> > error fields in plpgsql.
    >> >
    >> > Patch gets applied cleanly. make and make install too went smooth. make
    >> > check
    >> > was smooth too. Patch also include test coverage
    >> >
    >> > I tested the functionality with manual test and its woking as expected.
    >> >
    >> > BTW in the patch I found one additional new like in
    >> > read_raise_options():
    >> >
    >> > @@ -3631,7 +3661,23 @@ read_raise_options(void)
    >> >                 else if (tok_is_keyword(tok, &yylval,
    >> >                                                                 K_HINT,
    >> > "hint"))
    >> >                         opt->opt_type = PLPGSQL_RAISEOPTION_HINT;
    >> > +               else if (tok_is_keyword(tok, &yylval,
    >> > +
    >> > K_COLUMN_NAME, "column_name"))
    >> > +                       opt->opt_type = PLPGSQL_RAISEOPTION_COLUMN_NAME;
    >> > +               else if (tok_is_keyword(tok, &yylval,
    >> > +
    >> > K_CONSTRAINT_NAME, "constraint_name"))
    >> > +                       opt->opt_type =
    >> > PLPGSQL_RAISEOPTION_CONSTRAINT_NAME;
    >> > +               else if (tok_is_keyword(tok, &yylval,
    >> > +
    >> > K_DATATYPE_NAME, "datatype_name"))
    >> > +                       opt->opt_type =
    >> > PLPGSQL_RAISEOPTION_DATATYPE_NAME;
    >> > +               else if (tok_is_keyword(tok, &yylval,
    >> > +
    >> > K_TABLE_NAME, "table_name"))
    >> > +                       opt->opt_type = PLPGSQL_RAISEOPTION_TABLE_NAME;
    >> > +               else if (tok_is_keyword(tok, &yylval,
    >> > +
    >> > K_SCHEMA_NAME, "schema_name"))
    >> > +                       opt->opt_type = PLPGSQL_RAISEOPTION_SCHEMA_NAME;
    >> >                 else
    >> > +
    >> >                         yyerror("unrecognized RAISE statement option");
    >> >
    >> > can you please remove that.
    >>
    >> No, these fields are there as was proposed - it enhance possibilities
    >> to PLpgSQL developers - they can use these fields for custom
    >> exceptions. It is same like possibility to specify SQLCODE, MESSAGE,
    >> HINT in current RAISE statement implementation.
    >>
    >> Why you dislike it?
    >
    >
    > Seems like some confusion.
    >
    > I noticed additional new line which has been added into your patch in
    > function
    > read_raise_options()::pl_gram.y @ line number 3680. And in the earlier mail
    > thats what I asked to remove.
    >
    I am sorry
    
    I remove these new lines
    
    Regards
    
    Pavel
    >
    >
    >>
    >> Regards
    >>
    >> Pavel
    >>
    >> >
    >> > Apart from that patch looks good to me.
    >> >
    >> > Thanks,
    >> > Rushabh
    >> >
    >> >
    >> > On Fri, Feb 1, 2013 at 7:29 PM, Pavel Stehule <pavel.stehule@gmail.com>
    >> > wrote:
    >> >>
    >> >> 2013/2/1 Pavel Stehule <pavel.stehule@gmail.com>:
    >> >> > 2013/2/1 Peter Eisentraut <peter_e@gmx.net>:
    >> >> >> On 2/1/13 8:00 AM, Pavel Stehule wrote:
    >> >> >>> 2013/2/1 Marko Tiikkaja <pgmail@joh.to>:
    >> >> >>>> On 2/1/13 1:47 PM, Pavel Stehule wrote:
    >> >> >>>>>
    >> >> >>>>> now a most "hard" work is done and I would to enable access to
    >> >> >>>>> new
    >> >> >>>>> error fields from plpgsql.
    >> >> >>>>
    >> >> >>>>
    >> >> >>>> Is there a compelling reason why we wouldn't provide these already
    >> >> >>>> in
    >> >> >>>> 9.3?
    >> >> >>>
    >> >> >>> a time for assign to last commitfest is out.
    >> >> >>>
    >> >> >>> this patch is relative simple and really close to enhanced error
    >> >> >>> fields feature - but depends if some from commiters will have a
    >> >> >>> time
    >> >> >>> for commit to 9.3 - so I am expecting primary target 9.4, but I am
    >> >> >>> not
    >> >> >>> be angry if it will be commited early.
    >> >> >>
    >> >> >> If we don't have access to those fields on PL/pgSQL, what was the
    >> >> >> point
    >> >> >> of the patch to begin with?  Surely, accessing them from C wasn't
    >> >> >> the
    >> >> >> main use case?
    >> >> >>
    >> >> >
    >> >> > These fields are available for application developers now. But is a
    >> >> > true, so without this patch, GET STACKED DIAGNOSTICS statement will
    >> >> > not be fully consistent, because some fields are accessible and
    >> >> > others
    >> >> > not
    >> >>
    >> >> there is one stronger argument for commit this patch now. With this
    >> >> patch, we are able to wrote regression tests for new fields via
    >> >> plpgsql.
    >> >>
    >> >> Regards
    >> >>
    >> >> Pavel
    >> >>
    >> >> >
    >> >> > Pavel
    >> >>
    >> >>
    >> >> --
    >> >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
    >> >> To make changes to your subscription:
    >> >> http://www.postgresql.org/mailpref/pgsql-hackers
    >> >
    >> >
    >> >
    >> >
    >> > --
    >> > Rushabh Lathia
    >
    >
    >
    >
    > --
    > Rushabh Lathia
    
    
    

11. Re: proposal: enable new error fields in plpgsql (9.4)

    Pavel Stehule <pavel.stehule@gmail.com> — 2013-06-25T13:56:27Z

    Hello
    
    
    
    2013/6/25 Rushabh Lathia <rushabh.lathia@gmail.com>:
    > Hi Pavel,
    >
    > I gone through the discussion over here and found that with this patch we
    > enable the new error fields in plpgsql. Its a simple patch to expose the new
    > error fields in plpgsql.
    >
    > Patch gets applied cleanly. make and make install too went smooth. make
    > check
    > was smooth too. Patch also include test coverage
    >
    > I tested the functionality with manual test and its woking as expected.
    >
    > BTW in the patch I found one additional new like in read_raise_options():
    >
    > @@ -3631,7 +3661,23 @@ read_raise_options(void)
    >                 else if (tok_is_keyword(tok, &yylval,
    >                                                                 K_HINT,
    > "hint"))
    >                         opt->opt_type = PLPGSQL_RAISEOPTION_HINT;
    > +               else if (tok_is_keyword(tok, &yylval,
    > +
    > K_COLUMN_NAME, "column_name"))
    > +                       opt->opt_type = PLPGSQL_RAISEOPTION_COLUMN_NAME;
    > +               else if (tok_is_keyword(tok, &yylval,
    > +
    > K_CONSTRAINT_NAME, "constraint_name"))
    > +                       opt->opt_type = PLPGSQL_RAISEOPTION_CONSTRAINT_NAME;
    > +               else if (tok_is_keyword(tok, &yylval,
    > +
    > K_DATATYPE_NAME, "datatype_name"))
    > +                       opt->opt_type = PLPGSQL_RAISEOPTION_DATATYPE_NAME;
    > +               else if (tok_is_keyword(tok, &yylval,
    > +
    > K_TABLE_NAME, "table_name"))
    > +                       opt->opt_type = PLPGSQL_RAISEOPTION_TABLE_NAME;
    > +               else if (tok_is_keyword(tok, &yylval,
    > +
    > K_SCHEMA_NAME, "schema_name"))
    > +                       opt->opt_type = PLPGSQL_RAISEOPTION_SCHEMA_NAME;
    >                 else
    > +
    >                         yyerror("unrecognized RAISE statement option");
    >
    > can you please remove that.
    
    cleaned patch is in attachment
    
    >
    > Apart from that patch looks good to me.
    
    :) thank you for review
    
    Regards
    
    Pavel Stehule
    
    >
    > Thanks,
    > Rushabh
    >
    >
    > On Fri, Feb 1, 2013 at 7:29 PM, Pavel Stehule <pavel.stehule@gmail.com>
    > wrote:
    >>
    >> 2013/2/1 Pavel Stehule <pavel.stehule@gmail.com>:
    >> > 2013/2/1 Peter Eisentraut <peter_e@gmx.net>:
    >> >> On 2/1/13 8:00 AM, Pavel Stehule wrote:
    >> >>> 2013/2/1 Marko Tiikkaja <pgmail@joh.to>:
    >> >>>> On 2/1/13 1:47 PM, Pavel Stehule wrote:
    >> >>>>>
    >> >>>>> now a most "hard" work is done and I would to enable access to new
    >> >>>>> error fields from plpgsql.
    >> >>>>
    >> >>>>
    >> >>>> Is there a compelling reason why we wouldn't provide these already in
    >> >>>> 9.3?
    >> >>>
    >> >>> a time for assign to last commitfest is out.
    >> >>>
    >> >>> this patch is relative simple and really close to enhanced error
    >> >>> fields feature - but depends if some from commiters will have a time
    >> >>> for commit to 9.3 - so I am expecting primary target 9.4, but I am not
    >> >>> be angry if it will be commited early.
    >> >>
    >> >> If we don't have access to those fields on PL/pgSQL, what was the point
    >> >> of the patch to begin with?  Surely, accessing them from C wasn't the
    >> >> main use case?
    >> >>
    >> >
    >> > These fields are available for application developers now. But is a
    >> > true, so without this patch, GET STACKED DIAGNOSTICS statement will
    >> > not be fully consistent, because some fields are accessible and others
    >> > not
    >>
    >> there is one stronger argument for commit this patch now. With this
    >> patch, we are able to wrote regression tests for new fields via
    >> plpgsql.
    >>
    >> Regards
    >>
    >> Pavel
    >>
    >> >
    >> > Pavel
    >>
    >>
    >> --
    >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
    >> To make changes to your subscription:
    >> http://www.postgresql.org/mailpref/pgsql-hackers
    >
    >
    >
    >
    > --
    > Rushabh Lathia
    

12. Re: proposal: enable new error fields in plpgsql (9.4)

    Noah Misch <noah@leadboat.com> — 2013-06-27T22:35:20Z

    On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
    > cleaned patch is in attachment
    
    Of the five options you're adding to GET STACKED DIAGNOSTICS, four of them
    appear in the SQL standard.  DATATYPE_NAME does not; I think we should call it
    PG_DATATYPE_NAME in line with our other extensions in this area.
    
    
    > >> 2013/2/1 Pavel Stehule <pavel.stehule@gmail.com>:
    > >> > 2013/2/1 Peter Eisentraut <peter_e@gmx.net>:
    > >> >> On 2/1/13 8:00 AM, Pavel Stehule wrote:
    > >> >>> 2013/2/1 Marko Tiikkaja <pgmail@joh.to>:
    > >> >>>> Is there a compelling reason why we wouldn't provide these already in
    > >> >>>> 9.3?
    > >> >>>
    > >> >>> a time for assign to last commitfest is out.
    > >> >>>
    > >> >>> this patch is relative simple and really close to enhanced error
    > >> >>> fields feature - but depends if some from commiters will have a time
    > >> >>> for commit to 9.3 - so I am expecting primary target 9.4, but I am not
    > >> >>> be angry if it will be commited early.
    > >> >>
    > >> >> If we don't have access to those fields on PL/pgSQL, what was the point
    > >> >> of the patch to begin with?  Surely, accessing them from C wasn't the
    > >> >> main use case?
    > >> >>
    > >> >
    > >> > These fields are available for application developers now. But is a
    > >> > true, so without this patch, GET STACKED DIAGNOSTICS statement will
    > >> > not be fully consistent, because some fields are accessible and others
    > >> > not
    
    I am inclined to back-patch this to 9.3.  The patch is fairly mechanical, and
    I think the risk of introducing bugs is less than the risk that folks will be
    confused by these new-in-9.3 error fields being accessible from libpq and the
    protocol, yet inaccessible from PL/pgSQL.
    
    
    The existing protocol documentation says things like this:
    
            Table name: if the error was associated with a specific table, the
            name of the table.  (When this field is present, the schema name field
            provides the name of the table's schema.)
    
    The way you have defined RAISE does not enforce this; the user can set
    TABLE_NAME without setting SCHEMA_NAME at all.  I see a few options here:
    
    1. Change RAISE to check the invariants thoroughly.  For example, TABLE_NAME
    would require SCHEMA name, and the pair would need to name an actual table.
    
    2. Change RAISE to check the invariants simply.  For example, it could check
    that SCHEMA_NAME is present whenever TABLE_NAME is present but provide no
    validation that the pair names an actual table.  (I think the protocol
    language basically allows this, though a brief note wouldn't hurt.)
    
    3. Tweak the protocol documentation to clearly permit what the patch has RAISE
    allow, namely the free-form use of these fields.  This part of the protocol is
    new in 9.3, so it won't be a big deal to change it.  The libpq documentation
    has similar verbiage to update.
    
    I suppose I prefer #3.  It seems fair for user code to employ these fields for
    applications slightly broader than their core use, like a constraint name that
    represents some userspace notion of a constraint rather than normal, cataloged
    constraint.  I can also imagine an application like replaying logs from
    another server, recreating the messages as that server emitted them; #2 or #3
    would suffice for that.
    
    Looking beyond the immediate topic of PL/pgSQL, it seems fair for a FDW to use
    these error fields to name remote objects not known locally.  Suppose a
    foreign INSERT fires a remote trigger, and that trigger violates a constraint
    of some other remote table.  Naming the remote objects would be a reasonable
    design choice.  postgres_fdw might have chosen to just copy fields from the
    remote error (it does not do this today for the fields in question, though).
    The FDW might not even have a notion of a schema, at which point it would
    legitimately choose to leave that field unpopulated.  Once we allow any part
    of the system to generate such errors, we should let PL/pgSQL do the same.
    
    
    Thoughts on that plan?
    
    -- 
    Noah Misch
    EnterpriseDB                                 http://www.enterprisedb.com
    
    
    

13. Re: proposal: enable new error fields in plpgsql (9.4)

    Pavel Stehule <pavel.stehule@gmail.com> — 2013-06-28T05:49:46Z

    Hello
    
    2013/6/28 Noah Misch <noah@leadboat.com>:
    > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
    >> cleaned patch is in attachment
    >
    > Of the five options you're adding to GET STACKED DIAGNOSTICS, four of them
    > appear in the SQL standard.  DATATYPE_NAME does not; I think we should call it
    > PG_DATATYPE_NAME in line with our other extensions in this area.
    >
    
    yes, but It should be fixed in 9.3 enhanced fields too - it should be
    consistent with PostgreSQL fields
    
    
    >
    >> >> 2013/2/1 Pavel Stehule <pavel.stehule@gmail.com>:
    >> >> > 2013/2/1 Peter Eisentraut <peter_e@gmx.net>:
    >> >> >> On 2/1/13 8:00 AM, Pavel Stehule wrote:
    >> >> >>> 2013/2/1 Marko Tiikkaja <pgmail@joh.to>:
    >> >> >>>> Is there a compelling reason why we wouldn't provide these already in
    >> >> >>>> 9.3?
    >> >> >>>
    >> >> >>> a time for assign to last commitfest is out.
    >> >> >>>
    >> >> >>> this patch is relative simple and really close to enhanced error
    >> >> >>> fields feature - but depends if some from commiters will have a time
    >> >> >>> for commit to 9.3 - so I am expecting primary target 9.4, but I am not
    >> >> >>> be angry if it will be commited early.
    >> >> >>
    >> >> >> If we don't have access to those fields on PL/pgSQL, what was the point
    >> >> >> of the patch to begin with?  Surely, accessing them from C wasn't the
    >> >> >> main use case?
    >> >> >>
    >> >> >
    >> >> > These fields are available for application developers now. But is a
    >> >> > true, so without this patch, GET STACKED DIAGNOSTICS statement will
    >> >> > not be fully consistent, because some fields are accessible and others
    >> >> > not
    >
    > I am inclined to back-patch this to 9.3.  The patch is fairly mechanical, and
    > I think the risk of introducing bugs is less than the risk that folks will be
    > confused by these new-in-9.3 error fields being accessible from libpq and the
    > protocol, yet inaccessible from PL/pgSQL.
    >
    
    +1
    
    >
    > The existing protocol documentation says things like this:
    >
    >         Table name: if the error was associated with a specific table, the
    >         name of the table.  (When this field is present, the schema name field
    >         provides the name of the table's schema.)
    >
    > The way you have defined RAISE does not enforce this; the user can set
    > TABLE_NAME without setting SCHEMA_NAME at all.  I see a few options here:
    >
    > 1. Change RAISE to check the invariants thoroughly.  For example, TABLE_NAME
    > would require SCHEMA name, and the pair would need to name an actual table.
    >
    > 2. Change RAISE to check the invariants simply.  For example, it could check
    > that SCHEMA_NAME is present whenever TABLE_NAME is present but provide no
    > validation that the pair names an actual table.  (I think the protocol
    > language basically allows this, though a brief note wouldn't hurt.)
    >
    > 3. Tweak the protocol documentation to clearly permit what the patch has RAISE
    > allow, namely the free-form use of these fields.  This part of the protocol is
    > new in 9.3, so it won't be a big deal to change it.  The libpq documentation
    > has similar verbiage to update.
    >
    > I suppose I prefer #3.  It seems fair for user code to employ these fields for
    > applications slightly broader than their core use, like a constraint name that
    > represents some userspace notion of a constraint rather than normal, cataloged
    > constraint.  I can also imagine an application like replaying logs from
    > another server, recreating the messages as that server emitted them; #2 or #3
    > would suffice for that.
    >
    
    I like #3 too. These fields should be used in custom code freely - and
    I don't would create some limits. Developer can use it for application
    code how he likes. It was designed for this purpose.
    
    > Looking beyond the immediate topic of PL/pgSQL, it seems fair for a FDW to use
    > these error fields to name remote objects not known locally.  Suppose a
    > foreign INSERT fires a remote trigger, and that trigger violates a constraint
    > of some other remote table.  Naming the remote objects would be a reasonable
    > design choice.  postgres_fdw might have chosen to just copy fields from the
    > remote error (it does not do this today for the fields in question, though).
    > The FDW might not even have a notion of a schema, at which point it would
    > legitimately choose to leave that field unpopulated.  Once we allow any part
    > of the system to generate such errors, we should let PL/pgSQL do the same.
    
    +1
    
    Regards
    
    Pavel
    
    >
    >
    > Thoughts on that plan?
    >
    > --
    > Noah Misch
    > EnterpriseDB                                 http://www.enterprisedb.com
    
    
    

14. Re: proposal: enable new error fields in plpgsql (9.4)

    Noah Misch <noah@leadboat.com> — 2013-06-28T13:20:26Z

    On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
    > 2013/6/28 Noah Misch <noah@leadboat.com>:
    > > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
    > >> cleaned patch is in attachment
    > >
    > > Of the five options you're adding to GET STACKED DIAGNOSTICS, four of them
    > > appear in the SQL standard.  DATATYPE_NAME does not; I think we should call it
    > > PG_DATATYPE_NAME in line with our other extensions in this area.
    > >
    > 
    > yes, but It should be fixed in 9.3 enhanced fields too - it should be
    > consistent with PostgreSQL fields
    
    What else, specifically, should be renamed?  (Alternately, would you prepare a
    new version of the patch incorporating the proper name changes?)
    
    Thanks,
    nm
    
    -- 
    Noah Misch
    EnterpriseDB                                 http://www.enterprisedb.com
    
    
    

15. Re: proposal: enable new error fields in plpgsql (9.4)

    Pavel Stehule <pavel.stehule@gmail.com> — 2013-06-28T13:31:00Z

    Hello
    
    2013/6/28 Noah Misch <noah@leadboat.com>:
    > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
    >> 2013/6/28 Noah Misch <noah@leadboat.com>:
    >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
    >> >> cleaned patch is in attachment
    >> >
    >> > Of the five options you're adding to GET STACKED DIAGNOSTICS, four of them
    >> > appear in the SQL standard.  DATATYPE_NAME does not; I think we should call it
    >> > PG_DATATYPE_NAME in line with our other extensions in this area.
    >> >
    >>
    >> yes, but It should be fixed in 9.3 enhanced fields too - it should be
    >> consistent with PostgreSQL fields
    >
    > What else, specifically, should be renamed?  (Alternately, would you prepare a
    > new version of the patch incorporating the proper name changes?)
    
    I looked to source code, and identifiers in our source code are
    consistent, so my comment hasn't sense. Yes, I agree, so only
    identifier used in GET DIAGNOSTICS statement should be renamed. So,
    only DATATYPE_NAME should be renamed to PG_DATATYPE_NAME.
    
    Regards
    
    Pavel
    
    >
    > Thanks,
    > nm
    >
    > --
    > Noah Misch
    > EnterpriseDB                                 http://www.enterprisedb.com
    
    
    

16. Re: proposal: enable new error fields in plpgsql (9.4)

    Noah Misch <noah@leadboat.com> — 2013-06-28T15:11:03Z

    On Fri, Jun 28, 2013 at 03:31:00PM +0200, Pavel Stehule wrote:
    > Hello
    > 
    > 2013/6/28 Noah Misch <noah@leadboat.com>:
    > > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
    > >> 2013/6/28 Noah Misch <noah@leadboat.com>:
    > >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
    > >> >> cleaned patch is in attachment
    > >> >
    > >> > Of the five options you're adding to GET STACKED DIAGNOSTICS, four of them
    > >> > appear in the SQL standard.  DATATYPE_NAME does not; I think we should call it
    > >> > PG_DATATYPE_NAME in line with our other extensions in this area.
    > >> >
    > >>
    > >> yes, but It should be fixed in 9.3 enhanced fields too - it should be
    > >> consistent with PostgreSQL fields
    > >
    > > What else, specifically, should be renamed?  (Alternately, would you prepare a
    > > new version of the patch incorporating the proper name changes?)
    > 
    > I looked to source code, and identifiers in our source code are
    > consistent, so my comment hasn't sense. Yes, I agree, so only
    > identifier used in GET DIAGNOSTICS statement should be renamed. So,
    > only DATATYPE_NAME should be renamed to PG_DATATYPE_NAME.
    
    Okay.  I failed to note the first time through that while the patch uses the
    same option names for RAISE and GET STACKED DIAGNOSTICS, the existing option
    lists for those commands differ:
    
    --RAISE option--    --GET STACKED DIAGNOSTICS option--
    ERRCODE             RETURNED_SQLSTATE
    MESSAGE             MESSAGE_TEXT
    DETAIL              PG_EXCEPTION_DETAIL
    HINT                PG_EXCEPTION_HINT
    CONTEXT             PG_EXCEPTION_CONTEXT
    
    To be consistent with that pattern, I think we would use COLUMN, CONSTRAINT,
    TABLE, TYPE and SCHEMA as the new RAISE options.
    
    -- 
    Noah Misch
    EnterpriseDB                                 http://www.enterprisedb.com
    
    
    

17. Re: proposal: enable new error fields in plpgsql (9.4)

    Pavel Stehule <pavel.stehule@gmail.com> — 2013-06-28T15:21:29Z

    2013/6/28 Noah Misch <noah@leadboat.com>:
    > On Fri, Jun 28, 2013 at 03:31:00PM +0200, Pavel Stehule wrote:
    >> Hello
    >>
    >> 2013/6/28 Noah Misch <noah@leadboat.com>:
    >> > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
    >> >> 2013/6/28 Noah Misch <noah@leadboat.com>:
    >> >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
    >> >> >> cleaned patch is in attachment
    >> >> >
    >> >> > Of the five options you're adding to GET STACKED DIAGNOSTICS, four of them
    >> >> > appear in the SQL standard.  DATATYPE_NAME does not; I think we should call it
    >> >> > PG_DATATYPE_NAME in line with our other extensions in this area.
    >> >> >
    >> >>
    >> >> yes, but It should be fixed in 9.3 enhanced fields too - it should be
    >> >> consistent with PostgreSQL fields
    >> >
    >> > What else, specifically, should be renamed?  (Alternately, would you prepare a
    >> > new version of the patch incorporating the proper name changes?)
    >>
    >> I looked to source code, and identifiers in our source code are
    >> consistent, so my comment hasn't sense. Yes, I agree, so only
    >> identifier used in GET DIAGNOSTICS statement should be renamed. So,
    >> only DATATYPE_NAME should be renamed to PG_DATATYPE_NAME.
    >
    > Okay.  I failed to note the first time through that while the patch uses the
    > same option names for RAISE and GET STACKED DIAGNOSTICS, the existing option
    > lists for those commands differ:
    >
    > --RAISE option--    --GET STACKED DIAGNOSTICS option--
    > ERRCODE             RETURNED_SQLSTATE
    > MESSAGE             MESSAGE_TEXT
    > DETAIL              PG_EXCEPTION_DETAIL
    > HINT                PG_EXCEPTION_HINT
    > CONTEXT             PG_EXCEPTION_CONTEXT
    >
    > To be consistent with that pattern, I think we would use COLUMN, CONSTRAINT,
    > TABLE, TYPE and SCHEMA as the new RAISE options.
    
    I understand to your motivation, but I am not sure. Minimally word
    "TYPE" is too general. I have not strong opinion in this area. maybe
    DATATYPE ??
    
    p.s. you cannot to specify CONTEXT in RAISE statement
    
    Regards
    
    Pavel
    
    >
    > --
    > Noah Misch
    > EnterpriseDB                                 http://www.enterprisedb.com
    
    
    

18. Re: proposal: enable new error fields in plpgsql (9.4)

    Noah Misch <noah@leadboat.com> — 2013-06-28T16:08:21Z

    On Fri, Jun 28, 2013 at 05:21:29PM +0200, Pavel Stehule wrote:
    > 2013/6/28 Noah Misch <noah@leadboat.com>:
    > > Okay.  I failed to note the first time through that while the patch uses the
    > > same option names for RAISE and GET STACKED DIAGNOSTICS, the existing option
    > > lists for those commands differ:
    > >
    > > --RAISE option--    --GET STACKED DIAGNOSTICS option--
    > > ERRCODE             RETURNED_SQLSTATE
    > > MESSAGE             MESSAGE_TEXT
    > > DETAIL              PG_EXCEPTION_DETAIL
    > > HINT                PG_EXCEPTION_HINT
    > > CONTEXT             PG_EXCEPTION_CONTEXT
    > >
    > > To be consistent with that pattern, I think we would use COLUMN, CONSTRAINT,
    > > TABLE, TYPE and SCHEMA as the new RAISE options.
    > 
    > I understand to your motivation, but I am not sure. Minimally word
    > "TYPE" is too general. I have not strong opinion in this area. maybe
    > DATATYPE ??
    
    I'm not positive either.  DATATYPE rather than TYPE makes sense.
    
    > p.s. you cannot to specify CONTEXT in RAISE statement
    
    Oops; right.
    
    -- 
    Noah Misch
    EnterpriseDB                                 http://www.enterprisedb.com
    
    
    

19. Re: proposal: enable new error fields in plpgsql (9.4)

    Noah Misch <noah@leadboat.com> — 2013-07-02T20:22:00Z

    On Fri, Jun 28, 2013 at 12:08:21PM -0400, Noah Misch wrote:
    > On Fri, Jun 28, 2013 at 05:21:29PM +0200, Pavel Stehule wrote:
    > > 2013/6/28 Noah Misch <noah@leadboat.com>:
    > > > Okay.  I failed to note the first time through that while the patch uses the
    > > > same option names for RAISE and GET STACKED DIAGNOSTICS, the existing option
    > > > lists for those commands differ:
    > > >
    > > > --RAISE option--    --GET STACKED DIAGNOSTICS option--
    > > > ERRCODE             RETURNED_SQLSTATE
    > > > MESSAGE             MESSAGE_TEXT
    > > > DETAIL              PG_EXCEPTION_DETAIL
    > > > HINT                PG_EXCEPTION_HINT
    > > > CONTEXT             PG_EXCEPTION_CONTEXT
    > > >
    > > > To be consistent with that pattern, I think we would use COLUMN, CONSTRAINT,
    > > > TABLE, TYPE and SCHEMA as the new RAISE options.
    > > 
    > > I understand to your motivation, but I am not sure. Minimally word
    > > "TYPE" is too general. I have not strong opinion in this area. maybe
    > > DATATYPE ??
    > 
    > I'm not positive either.  DATATYPE rather than TYPE makes sense.
    
    Here's a revision bearing the discussed name changes and protocol
    documentation tweaks, along with some cosmetic adjustments.  If this seems
    good to you, I will commit it.
    
    -- 
    Noah Misch
    EnterpriseDB                                 http://www.enterprisedb.com
    

20. Re: proposal: enable new error fields in plpgsql (9.4)

    Pavel Stehule <pavel.stehule@gmail.com> — 2013-07-03T04:17:18Z

    Hello
    
    2013/7/2 Noah Misch <noah@leadboat.com>:
    > On Fri, Jun 28, 2013 at 12:08:21PM -0400, Noah Misch wrote:
    >> On Fri, Jun 28, 2013 at 05:21:29PM +0200, Pavel Stehule wrote:
    >> > 2013/6/28 Noah Misch <noah@leadboat.com>:
    >> > > Okay.  I failed to note the first time through that while the patch uses the
    >> > > same option names for RAISE and GET STACKED DIAGNOSTICS, the existing option
    >> > > lists for those commands differ:
    >> > >
    >> > > --RAISE option--    --GET STACKED DIAGNOSTICS option--
    >> > > ERRCODE             RETURNED_SQLSTATE
    >> > > MESSAGE             MESSAGE_TEXT
    >> > > DETAIL              PG_EXCEPTION_DETAIL
    >> > > HINT                PG_EXCEPTION_HINT
    >> > > CONTEXT             PG_EXCEPTION_CONTEXT
    >> > >
    >> > > To be consistent with that pattern, I think we would use COLUMN, CONSTRAINT,
    >> > > TABLE, TYPE and SCHEMA as the new RAISE options.
    >> >
    >> > I understand to your motivation, but I am not sure. Minimally word
    >> > "TYPE" is too general. I have not strong opinion in this area. maybe
    >> > DATATYPE ??
    >>
    >> I'm not positive either.  DATATYPE rather than TYPE makes sense.
    >
    > Here's a revision bearing the discussed name changes and protocol
    > documentation tweaks, along with some cosmetic adjustments.  If this seems
    > good to you, I will commit it.
    >
    
    +1
    
    Pavel
    
    > --
    > Noah Misch
    > EnterpriseDB                                 http://www.enterprisedb.com
    
    
    

21. Re: proposal: enable new error fields in plpgsql (9.4)

    Noah Misch <noah@leadboat.com> — 2013-07-03T11:46:33Z

    On Wed, Jul 03, 2013 at 06:17:18AM +0200, Pavel Stehule wrote:
    > 2013/7/2 Noah Misch <noah@leadboat.com>:
    > > Here's a revision bearing the discussed name changes and protocol
    > > documentation tweaks, along with some cosmetic adjustments.  If this seems
    > > good to you, I will commit it.
    > 
    > +1
    
    Done.
    
    Rushabh, I neglected to credit you as a reviewer and realized it too late.
    Sorry about that.
    
    -- 
    Noah Misch
    EnterpriseDB                                 http://www.enterprisedb.com
    
    
    

22. Re: proposal: enable new error fields in plpgsql (9.4)

    Pavel Stehule <pavel.stehule@gmail.com> — 2013-07-03T11:51:02Z

    2013/7/3 Noah Misch <noah@leadboat.com>:
    > On Wed, Jul 03, 2013 at 06:17:18AM +0200, Pavel Stehule wrote:
    >> 2013/7/2 Noah Misch <noah@leadboat.com>:
    >> > Here's a revision bearing the discussed name changes and protocol
    >> > documentation tweaks, along with some cosmetic adjustments.  If this seems
    >> > good to you, I will commit it.
    >>
    >> +1
    >
    > Done.
    
    Thank you, very much
    
    Regards
    
    Pavel
    
    >
    > Rushabh, I neglected to credit you as a reviewer and realized it too late.
    > Sorry about that.
    >
    > --
    > Noah Misch
    > EnterpriseDB                                 http://www.enterprisedb.com
    
    
    

23. Re: proposal: enable new error fields in plpgsql (9.4)

    Rushabh Lathia <rushabh.lathia@gmail.com> — 2013-07-15T11:55:14Z

    On Wed, Jul 3, 2013 at 5:16 PM, Noah Misch <noah@leadboat.com> wrote:
    
    > On Wed, Jul 03, 2013 at 06:17:18AM +0200, Pavel Stehule wrote:
    > > 2013/7/2 Noah Misch <noah@leadboat.com>:
    > > > Here's a revision bearing the discussed name changes and protocol
    > > > documentation tweaks, along with some cosmetic adjustments.  If this
    > seems
    > > > good to you, I will commit it.
    > >
    > > +1
    >
    > Done.
    >
    > Rushabh, I neglected to credit you as a reviewer and realized it too late.
    > Sorry about that.
    >
    
    Sorry somehow I missed this thread.
    
    Thanks Noah.
    
    
    >
    > --
    > Noah Misch
    > EnterpriseDB                                 http://www.enterprisedb.com
    >
    
    
    
    -- 
    Rushabh Lathia