On Wed, Jul 3, 2013 at 5:16 PM, Noah Misch wrote:
> On Wed, Jul 03, 2013 at 06:17:18AM +0200, Pavel Stehule wrote:
> > 2013/7/2 Noah Misch :
> > > Here's a revision bearing the discussed name changes and protocol
> > > documentation tweaks, along with some cosmetic adjustments. If this
> seems
>
2013/7/3 Noah Misch :
> On Wed, Jul 03, 2013 at 06:17:18AM +0200, Pavel Stehule wrote:
>> 2013/7/2 Noah Misch :
>> > 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.
On Wed, Jul 03, 2013 at 06:17:18AM +0200, Pavel Stehule wrote:
> 2013/7/2 Noah Misch :
> > 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 n
Hello
2013/7/2 Noah Misch :
> 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 :
>> > > Okay. I failed to note the first time through that while the patch uses
>> > > the
>> > > same option nam
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 :
> > > Okay. I failed to note the first time through that while the patch uses
> > > the
> > > same option names for RAISE and GET STACKED DIAGNOS
On Fri, Jun 28, 2013 at 05:21:29PM +0200, Pavel Stehule wrote:
> 2013/6/28 Noah Misch :
> > 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:
> >
> > --RA
2013/6/28 Noah Misch :
> On Fri, Jun 28, 2013 at 03:31:00PM +0200, Pavel Stehule wrote:
>> Hello
>>
>> 2013/6/28 Noah Misch :
>> > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
>> >> 2013/6/28 Noah Misch :
>> >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
>> >>
On Fri, Jun 28, 2013 at 03:31:00PM +0200, Pavel Stehule wrote:
> Hello
>
> 2013/6/28 Noah Misch :
> > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
> >> 2013/6/28 Noah Misch :
> >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote:
> >> >> cleaned patch is in attachm
Hello
2013/6/28 Noah Misch :
> On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
>> 2013/6/28 Noah Misch :
>> > 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, f
On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote:
> 2013/6/28 Noah Misch :
> > 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 sta
Hello
2013/6/28 Noah Misch :
> 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_DATAT
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 extensio
Hello
2013/6/25 Rushabh Lathia :
> 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 smoo
2013/6/25 Rushabh Lathia :
>
>
>
> On Tue, Jun 25, 2013 at 2:41 PM, Pavel Stehule
> wrote:
>>
>> 2013/6/25 Rushabh Lathia :
>> > 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 exp
On Tue, Jun 25, 2013 at 2:41 PM, Pavel Stehule wrote:
> 2013/6/25 Rushabh Lathia :
> > 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.
> >
> >
2013/6/25 Rushabh Lathia :
> 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
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 includ
2013/2/1 Pavel Stehule :
> 2013/2/1 Peter Eisentraut :
>> On 2/1/13 8:00 AM, Pavel Stehule wrote:
>>> 2013/2/1 Marko Tiikkaja :
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.
2013/2/1 Peter Eisentraut :
> On 2/1/13 8:00 AM, Pavel Stehule wrote:
>> 2013/2/1 Marko Tiikkaja :
>>> 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
On 2/1/13 8:00 AM, Pavel Stehule wrote:
> 2013/2/1 Marko Tiikkaja :
>> 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
2013/2/1 Marko Tiikkaja :
> 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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
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
23 matches
Mail list logo
