Re: Minor error in calling a python list a tuple
On 01.02.22 20:57, PG Doc comments form wrote: The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/plpython-data.html Description: Hello, In the link bellow there is the mentioned error. https://www.postgresql.org/docs/13/plpython-data.html#PLPYTHON-ARRAYS CREATE FUNCTION make_pair (name text, value integer) RETURNS named_value AS $$ return ( name, value ) # or alternatively, as tuple: return [ name, value ] $$ LANGUAGE plpythonu; Should be: # or alternatively, as list: return [ name, value ] Yes, this is a mistake. I have fixed it. Thanks.
Re: Minor error in calling a python list a tuple
Awesome. Thanks for the great work you are doing. All of you. Nasseh On Wed, Feb 2, 2022, 3:17 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 01.02.22 20:57, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/13/plpython-data.html > > Description: > > > > Hello, > > In the link bellow there is the mentioned error. > > https://www.postgresql.org/docs/13/plpython-data.html#PLPYTHON-ARRAYS > > > > CREATE FUNCTION make_pair (name text, value integer) > >RETURNS named_value > > AS $$ > >return ( name, value ) > ># or alternatively, as tuple: return [ name, value ] > > $$ LANGUAGE plpythonu; > > > > > > Should be: > ># or alternatively, as list: return [ name, value ] > > Yes, this is a mistake. I have fixed it. Thanks. >
Re: Conventions
On Wed, Jan 26, 2022 at 09:51:53PM -0500, Bruce Momjian wrote: > > I'd suggest a separate para at some point before the first usage, > > along the lines of > > > >In this section, we follow the usual Tcl convention of using question > >marks, rather than brackets, to indicate an optional element in a > >syntax synopsis. > > Oh, then I didn't understand it either. I know Tcl uses brackets for > stuff so I thought there was some weird syntax that represented brackets > as something else. Anyway, updated patch attached. Patch applied to all supported versions. Dave, thanks for pointing out this problem. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
Re: maximum number of backtrace frames logged by backtrace_functions
On 2022/02/02 16:20, Peter Eisentraut wrote: On 01.02.22 18:04, Fujii Masao wrote: The maximum number of backtrace frames logged by backtrace_functions is 100. Isn't it better to document this information so that users can understand not all backtrace always can be logged? Patch attached. The 100 was chosen as more than you'll ever need. If you are encountering cases with more than that, let's increase the limit. I encountered the "more than 100 backtrace frames" case when investigating the bug of pg_log_query_plan() patch [1]. Since the function that the patch added can be called repeatedly during call to that function, the backtrace became larger than 100. I think this is not general case, so basically 100 sounds enough limit size to me. OTOH I think it's helpful if the limit is documented when I occasionally encounter the case and want to understand why all backtrace frames are not logged. [1] https://commitfest.postgresql.org/37/3142/ Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
