Re: Mailing list not working
Hi, I also got same error couple of hours ago. Now it is working fine. It would be great to have alerting tools like prometheus to notify users when the server is down Regards, Ram.
Mailing list not working
Hi, I am not able to access the mailing list archive. Is the mailing list server down or something? -- Cheers Ram 4.0
Re: Contribution to Perldoc for TestLib module in Postgres
Hi, Please find the updated patch. Added to the commitfest as well Regards, Ram. v2_perldoc_testlib.patch.patch Description: Binary data
Re: Problem during Windows service start
Hi, Please find the proposed patch for review. I will attach it to commitfest as well Regards, Ram. windows_service_bug_fix_v2.patch Description: Binary data
Re: Problem during Windows service start
Hi, If wait_for_postmaster returns POSTMASTER_STILL_STARTING will it be correct to set the status of windows service to SERVICE_START_PENDING ? I would like to take this up if no one is working on this. Regards, Ram.
Re: Contribution to Perldoc for TestLib module in Postgres
Hi, Please find the first version of the patch for review. I was not sure what some of the functions are used for and marked them with TODO. Cheers Ram 4.0 v1_perldoc_testlib.patch Description: Binary data
Re: Contribution to Perldoc for TestLib module in Postgres
Hi, Can I take this up? Regards, Ram
Re: Unaccent extension python script Issue in Windows
Hi Hugh, I have abstracted out the windows compatibility changes from your patch to a new patch and tested it. Added the patch to https://commitfest.postgresql.org/23/ Please feel free to change it if it requires any changes. Cheers Ram 4.0 v1_unaccent_windows_compatibility.patch Description: Binary data
Unaccent extension python script Issue in Windows
Hi Hackers, In master branch, unaccent extension is having issue with the below python script.This issue is only in windows 10 and python 3. python generate_unaccent_rules.py --unicode-data-file UnicodeData.txt --latin-ascii-file Latin-ASCII.xml > unaccent.rules I am getting the following error UnicodeEncodeError: 'charmap' codec can't encode character '\u0100' in position 0: character maps to I went through the python script and found that the stdout encoding is set to utf-8 only if python version is <=2. The same needs to be done for python 3 -- Cheers Ram 4.0
Re: Add missing CREATE TABLE IF NOT EXISTS table_name AS EXECUTE query;
Hi, Will it be helpful if the comments section of ExecuteStmt in gram.y is updated to include the IF NOT EXISTS clause.Something like this CREATE TABLE [IF NOT EXISTS] AS EXECUTE [(params, ...)] Regards, Ram.
Re: psql show URL with help
Hi, Is there any documentation change required for this patch? Cheers Ram 4.0
Re: PostgreSQL vs SQL/XML Standards
Hi, Yes it is working fine with \a option in psql. Cheers Ram 4.0
Re: House style for DocBook documentation?
Hi,
I have tested bug fixes provided by all the patches. They are working
great. I found one minor issue
select * from xmltable('*' PASSING 'predeeppost' COLUMNS x XML PATH '/');
The above query returns the xml. But there is an extra plus symbol at the
end
predeeppost+
Regards,
Ram
Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context
Hi,
The below statement needs to be executed before running the query to
replicate the issue
update xmldata set data = regexp_replace(data::text, '791',
'791')::xml;
On Thu, 28 Feb 2019 at 17:55, Pavel Stehule wrote:
>
>
> čt 28. 2. 2019 v 10:31 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> čt 28. 2. 2019 v 9:58 odesílatel Ramanarayana
>> napsal:
>>
>>> Hi,
>>>
>>> I have tested the three issues fixed in patch 001. Array Indexes
>>> issue is still there.Running the following query returns ERROR: more
>>> than one value returned by column XPath expression
>>>
>>> SELECT xmltable.*
>>> FROM (SELECT data FROM xmldata) x,
>>> LATERAL XMLTABLE('/ROWS/ROW'
>>> PASSING data
>>> COLUMNS
>>> country_name text PATH 'COUNTRY_NAME/text()' NOT NULL,
>>> size_text float PATH 'SIZE/text()',
>>> size_text_1 float PATH 'SIZE/text()[1]',
>>> size_text_2 float PATH 'SIZE/text()[2]',
>>> "SIZE" float, size_xml xml PATH 'SIZE')
>>>
>>> The other two issues are resolved by this patch.
>>>
>>
> I tested xmltable-xpath-result-processing-bugfix-6.patch
>
> and it is working
>
> postgres=# SELECT xmltable.*
> postgres-#FROM (SELECT data FROM xmldata) x,
> postgres-# LATERAL XMLTABLE('/ROWS/ROW'
> postgres(# PASSING data
> postgres(# COLUMNS
> postgres(# country_name text PATH
> 'COUNTRY_NAME/text()' NOT NULL,
> postgres(# size_text float PATH
> 'SIZE/text()',
> postgres(# size_text_1 float PATH
> 'SIZE/text()[1]',
> postgres(# size_text_2 float PATH
> 'SIZE/text()[2]',
> postgres(# "SIZE" float, size_xml xml
> PATH 'SIZE') ;
> ┌──┬───┬─┬─┬──┬┐
>
> │ country_name │ size_text │ size_text_1 │ size_text_2 │ SIZE │
> size_xml │
> ╞══╪═══╪═╪═╪══╪╡
>
> │ Australia│ ∅ │ ∅ │ ∅ │∅ │
> ∅ │
> │ China│ ∅ │ ∅ │ ∅ │∅ │
> ∅ │
> │ HongKong │ ∅ │ ∅ │ ∅ │∅ │
> ∅ │
> │ India│ ∅ │ ∅ │ ∅ │∅ │
> ∅ │
> │ Japan│ ∅ │ ∅ │ ∅ │∅ │
> ∅ │
> │ Singapore│ 791 │ 791 │ ∅ │ 791 │ unit="km">791 │
> └──┴───┴─┴─┴──┴┘
>
> (6 rows)
>
> Regards
>
> Pavel
>
>
>>
>> what patches you are used?
>>
>> Regards
>>
>> Pavel
>>
>>
>>> --
>>> Cheers
>>> Ram 4.0
>>>
>>
--
Cheers
Ram 4.0
Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context
Hi,
I applied the following patches
0001-XML-XPath-comments-processing-instructions-array-ind.patch
<https://www.postgresql.org/message-id/attachment/63467/0001-XML-XPath-comments-processing-instructions-array-ind.patch>
0002-XML-avoid-xmlStrdup-if-possible.patch
<https://www.postgresql.org/message-id/attachment/63468/0002-XML-avoid-xmlStrdup-if-possible.patch>
Can you let me know what fix is done in patch 002. I will test that as well?
Regards,
Ram.
On Thu, 28 Feb 2019 at 15:01, Pavel Stehule wrote:
>
>
> čt 28. 2. 2019 v 9:58 odesílatel Ramanarayana
> napsal:
>
>> Hi,
>>
>> I have tested the three issues fixed in patch 001. Array Indexes
>> issue is still there.Running the following query returns ERROR: more
>> than one value returned by column XPath expression
>>
>> SELECT xmltable.*
>> FROM (SELECT data FROM xmldata) x,
>> LATERAL XMLTABLE('/ROWS/ROW'
>> PASSING data
>> COLUMNS
>> country_name text PATH 'COUNTRY_NAME/text()' NOT NULL,
>> size_text float PATH 'SIZE/text()',
>> size_text_1 float PATH 'SIZE/text()[1]',
>> size_text_2 float PATH 'SIZE/text()[2]',
>> "SIZE" float, size_xml xml PATH 'SIZE')
>>
>> The other two issues are resolved by this patch.
>>
>
> what patches you are used?
>
> Regards
>
> Pavel
>
>
>> --
>> Cheers
>> Ram 4.0
>>
>
--
Cheers
Ram 4.0
Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context
>
> Hi,
I have tested the three issues fixed in patch 001. Array Indexes
issue is still there.Running the following query returns ERROR: more than
one value returned by column XPath expression
SELECT xmltable.*
FROM (SELECT data FROM xmldata) x,
LATERAL XMLTABLE('/ROWS/ROW'
PASSING data
COLUMNS
country_name text PATH 'COUNTRY_NAME/text()' NOT NULL,
size_text float PATH 'SIZE/text()',
size_text_1 float PATH 'SIZE/text()[1]',
size_text_2 float PATH 'SIZE/text()[2]',
"SIZE" float, size_xml xml PATH 'SIZE')
The other two issues are resolved by this patch.
--
Cheers
Ram 4.0
Re: libpq debug log
Hi, I have tested the trace log implementation.Please find my feedback for the same. Issues found while testing - 1) If invalid value is given to PGLOGMINLEVEL, empty log file is created which should not happen. 2) If log file size exceeds the value configured in PGLOGSIZE, new log file is not getting created. 3) If PGLOGSIZE is greater than 2048 bytes, log file is not created.Is this expected behaviour? 4) In the log file, an extra new line is present whenever the query is printed.Is this intentional? 5)Documentation for this feature is having grammatical errors and some spelling errors which can be looked into. Feedback in the code -- 1) if else statement should be used for checking log levels rather than multiple if statements 2) Across the code, sufficient space need to be left between parameters in functions and while using comparison operators 3) In libpq-fe.h in the comments section it should trace rather than trce Suggestions -- -> Will it better if the logs of all processes are written to a single log file with the log message containing the process id rather than one log file per process?
Re: BUG #15548: Unaccent does not remove combining diacritical characters
Hi Hugh, The patch I submitted was tested both in python 2 and 3 and it worked for me.The single line of code added in the patch runs only in python 3. I dont think it can break python2. Would like to see the error you got in python 2 Good to know the reported issue is a valid one in windows.I tested your patch as well and it is also working fine. -- Cheers Ram 4.0
Re: libpq host/hostaddr/conninfo inconsistencies
Hi, I am getting error while applying patch.I think the patch needs to be redone on the latest code in master as there are some commits in master after the patch is created On Sat, 16 Feb 2019 at 13:44, Fabien COELHO wrote: > > Hello Kyotaro-san, > > > On such standpoint, the first hunk in the patch attracted my > > eyes. > > > > host > > > > > > -Name of host to connect to.host > name > > -If a host name begins with a slash, it specifies Unix-domain > > -communication rather than TCP/IP communication; the value is the > > -name of the directory in which the socket file is stored. > > + > > > > I don't think this is user-friendly since almost all of them don't write > > multiple hosts there. So I prefer the previous organization. > > ISTM that specifying the expected syntax is the first information needed? > > The previous organization says "this is a host name (bla bla bla) btw I > lied at the beginning this is a list". > > > The description about IP-address looks too verbose, especially we don't > > need explain what is IP-address here. > > Ok. > > I agree that the order is not the best possible one. Here is a simplified > and reordered version: > > """ Comma-separated list of hosts to connect to. Each item may be a host > name that will be resolved with a look-up, a numeric IP address that will > be used directly, or the name of a directory which contains the socket > file for Unix-domain communication, if the specification begins with a > slash. Each specified target will be tried in turn in the order given. See > for details. """ > > What do you think about that version. > > -- > Fabien. > > -- Cheers Ram 4.0
Re: BUG #15548: Unaccent does not remove combining diacritical characters
Hi Michael, The issue was that the python script was working in python 2 but not in python 3 in Windows. This is because the python script writes the final output to stdout and stdout encoding is set to utf-8 only for python 2 but not python 3.If no encoding is set for stdout it takes the encoding from the Operating system.Default encoding in linux and windows might be different.Hence this issue. Regards, Ram. On Tue, 12 Feb 2019 at 09:48, Michael Paquier wrote: > On Tue, Feb 12, 2019 at 02:27:31AM +0530, Ramanarayana wrote: > > I tested the script in python 2.7 and it works perfect. The problem is in > > python 3.7(and may be only in windows as you were not getting the issue) > > and I was getting the following error > > > > UnicodeEncodeError: 'charmap' codec can't encode character '\u0100' in > > position 0: character maps to > > > > I went through the python script and found that the stdout encoding is > set > > to utf-8 only if python version is <=2. > > > > I have made the same change for python version 3 as well. Please find the > > patch for the same.Let me know if it makes sense > > Isn't that because Windows encoding becomes cp1252, utf16 or such? > FWIW, on Debian SID with Python 3.7, I get the correct output, and no > diffs on HEAD. Perhaps it would make sense to use open() on the > different files with encoding='utf-8' to avoid any kind of problems? > -- > Michael > -- Cheers Ram 4.0
Re: BUG #15548: Unaccent does not remove combining diacritical characters
Hi Hugh, I tested the script in python 2.7 and it works perfect. The problem is in python 3.7(and may be only in windows as you were not getting the issue) and I was getting the following error UnicodeEncodeError: 'charmap' codec can't encode character '\u0100' in position 0: character maps to I went through the python script and found that the stdout encoding is set to utf-8 only if python version is <=2. I have made the same change for python version 3 as well. Please find the patch for the same.Let me know if it makes sense Regards, Ram. On Tue, 12 Feb 2019 at 00:50, Hugh Ranalli wrote: > > On Sun, 10 Feb 2019 at 15:07, raam narayana wrote: > >> Hi, >> >> After the latest commit in master branch, I was trying to test the python >> script. Ironically I still see that the output from the script is >> completely different from the unaccent.rules file content. Am I missing >> anything.My testing includes the following >> >> Downloaded the following files >> >> http://unicode.org/Public/8.0.0/ucd/UnicodeData.txt >> >> >> http://unicode.org/cldr/trac/export/14746/tags/release-34/common/transforms/Latin-ASCII.xml >> >> Executed the below python script >> >> python generate_unaccent_rules.py --unicode-data-file UnicodeData.txt >> --latin-ascii-file Latin-ASCII.xml > unaccent.rules >> >> I am using python 3.7.1 and running on Windows 10 Platform >> >> The new status of this patch is: Needs review >> > > Hi Raam, > I just ran generate_unaccent_rules.py under two environments, using the > data files given above : > - Python 3.4.3 on Linux Mint 17.3 (equivalent to Ubuntu 14.04) > - Python 3.6.7 on Ubuntu 18.04 > > In both cases, the output was identical to that generated by the program > under Python 2.7. So yes, more information would help. Unfortunately I > don't have a Windows Python environment readily available, but could set > one up if I had to. > > Thanks, > Hugh > -- Cheers Ram 4.0 generate_unaccent_rules-remove-combining-diacritical-accents-03.patch Description: Binary data
