[pgadmin-hackers] FTS nodes (Configuration, Dictionaries, Parser, Templates) patch
Hi Dave, PFA patch for FTS nodes. *Run test suite by following command:* python runtests.py -- Best, Priyanka EnterpriseDB Corporation The Enterprise PostgreSQL Company FTS_nodes.patch Description: Binary data -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] [PATCH] Document that a patch should be submitted to the list as an attachment
> > > /Users/dpage/Downloads/0001-Document-that-a-patch-should-be-submitted-to-the-lis.patch:16: > trailing whitespace. > > as well as the rationale for any important design decisions. > > error: patch failed: docs/en_US/submitting_patches.rst:30 > > error: docs/en_US/submitting_patches.rst: patch does not apply > > > > I checked and I can't see anything wrong. I also tried downloading the > patch from the web archive and using git apply. > > The "trailing whitespace" errors may suggest the problem - the added > lines in the patch don't have any whitespace. > Have you been near a Windows machine? I used unix2dos on the patch and > then got the same result as above. > > > No, I've only been on my Mac. Your suggestion made me think though - I opened > the patch in my editor, and it claims the original had Windows line endings. > I converted them to \n and it applied just fine. I think it's an email thing. From: https://github.com/git/git/commit/8d8140843501107c92e2f9a5acb60ee136352c1f "The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them." I have been using git send-email, to avoid the risk of a mail client mangling patches. But I can try using Thunderbird in future. I guess git imap-send behaviour is similar: http://www.spinics.net/lists/git/msg160136.html " > I'm using git imap-send to send patches to wine-patches, and it seems > like it converts all my patches to have CRLF line endings? The canonical line ending for mail is CRLF. So yes, it will convert your patch to CRLF for storage. But anything pulling it out of the IMAP folder should convert it back to native line endings." Testing locally the raw emails do have CRLF saved from Thunderbird as .eml, although when I save just the attachment the patch only has LF. Not sure why this hasn't been an issue before on the list. The Git tools seem to be more focussed on inline messages. On the receiving end using attachments the ideas I have: - Is there a save as text option in your client? - Save from the web archive > > What does 'git config core.autocrlf' output for you? The only core. attribute I have set is core.editor. > > In any case, I applied the patch. Thanks! > Hopefully we don't have to add more instructions as a result of this discussion... Chris -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] Foreign Table Patch
Hi Dave, PFA patch for Foreign Table node. *Run the test suite by following command:* python runtests.py Thank you. -- Best, Priyanka EnterpriseDB Corporation The Enterprise PostgreSQL Company FT.patch Description: Binary data -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] [PATCH] Document that a patch should be submitted to the list as an attachment
Hi On Wednesday, October 12, 2016, Chris Mayo wrote: > > > /Users/dpage/Downloads/0001-Document-that-a-patch-should- > be-submitted-to-the-lis.patch:16: trailing whitespace. > > > as well as the rationale for any important design decisions. > > > error: patch failed: docs/en_US/submitting_patches.rst:30 > > > error: docs/en_US/submitting_patches.rst: patch does not apply > > > > > > > I checked and I can't see anything wrong. I also tried downloading > the patch from the web archive and using git apply. > > > > The "trailing whitespace" errors may suggest the problem - the added > lines in the patch don't have any whitespace. > > Have you been near a Windows machine? I used unix2dos on the patch > and then got the same result as above. > > > > > > No, I've only been on my Mac. Your suggestion made me think though - I > opened the patch in my editor, and it claims the original had Windows line > endings. I converted them to \n and it applied just fine. > > I think it's an email thing. From: > https://github.com/git/git/commit/8d8140843501107c92e2f9a5acb60ee136352c1f > "The problem is that SMTP transport is CRLF-unsafe. Sending a patch by > email is the same as passing it through "dos2unix | unix2dos". The newly > introduced CRLFs are normally transparent because git-am strips them." > > I have been using git send-email, to avoid the risk of a mail client > mangling patches. > But I can try using Thunderbird in future. > > I guess git imap-send behaviour is similar: > http://www.spinics.net/lists/git/msg160136.html > " > > I'm using git imap-send to send patches to wine-patches, and it seems > > like it converts all my patches to have CRLF line endings? > > The canonical line ending for mail is CRLF. So yes, it will convert your > patch to CRLF for storage. But anything pulling it out of the IMAP > folder should convert it back to native line endings." > > > Testing locally the raw emails do have CRLF saved from Thunderbird as .eml, > although when I save just the attachment the patch only has LF. > > Not sure why this hasn't been an issue before on the list. > It has, on rare occasions. One particular friend of mine had to resort to gzipping patches for pgAdmin 4, but it's been a non-issue for pretty much everyone else here - and the process we use is pretty standard on the PostgreSQL lists as well, where it's also not generally a problem. Note that at least for those of us at EDB, Gmail is the standard client we use. I wonder if some combination of sending and receiving MUAs is what causes the problem. > > The Git tools seem to be more focussed on inline messages. On the > receiving end > using attachments the ideas I have: > - Is there a save as text option in your client? > You can view the original message in Gmail, but that's the entire raw text of it, so you get all the mime parts and headers as well. > - Save from the web archive > That's a possibility, though it's such a rare issue that I doubt we'll remember to do it. I'd really like to know the root cause - it's quite annoying not being able to pin it down. > > > > > What does 'git config core.autocrlf' output for you? > > The only core. attribute I have set is core.editor. > > > > > In any case, I applied the patch. Thanks! > > > > Hopefully we don't have to add more instructions as a result of this > discussion... > Well at least it's keeping you busy :-) Thanks, Dave. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: [pgadmin-hackers] [Patch][pgAdmin4]: RM#1577 - Debug option for function/procedure under package node
Hi Dave, On Fri, Oct 7, 2016 at 5:19 PM, Dave Page wrote: > Thanks, applied. Couple of questions/points: > > - If there is no body for a procedure, the error is handled somewhat > ungracefully - the message is displayed without line breaks, and the > debugger panel is left empty. Can we make that a little nicer? > OK, I will work on that. > > - In pgAdmin 3 there's a "Debug package initialiser?" option on the > parameter dialogue. Is that shown for appropriate packages? I don't > have an example to hand to test with. > Currently no option for "Debug package initialiser". I will submit updated patch for both above points. > > On Fri, Oct 7, 2016 at 11:55 AM, Neel Patel > wrote: > > Hi, > > > > Please find attached patch file which contains function/procedure debug > > support under package node. (RM #1577) > > > > Do review it and let me know for any comments. > > > > Thanks, > > Neel Patel > > > > > > -- > > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgadmin-hackers > > > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: [pgadmin-hackers] Foreign Table Patch
Please ignore previous patch, it was failing for EPAS servers. PFA revised
patch.
*Run the test suite by following command:*
python runtests.py
Thank you.
On 12 October 2016 at 07:39, Priyanka Shendge <
priyanka.shen...@enterprisedb.com> wrote:
> Hi Dave,
>
> PFA patch for Foreign Table node.
>
> *Run the test suite by following command:*
> python runtests.py
>
> Thank you.
>
> --
> Best,
> Priyanka
>
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
--
Best,
Priyanka
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
diff --git a/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/tests/__init__.py b/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/tests/__init__.py
new file mode 100644
index 000..b41fbba
--- /dev/null
+++ b/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/tests/__init__.py
@@ -0,0 +1,16 @@
+# #
+#
+# pgAdmin 4 - PostgreSQL Tools
+#
+# Copyright (C) 2013 - 2016, The pgAdmin Development Team
+# This software is released under the PostgreSQL Licence
+#
+# ##
+
+from pgadmin.utils.route import BaseTestGenerator
+
+
+class ForeignTableGeneratorTestCase(BaseTestGenerator):
+
+def runTest(self):
+return []
diff --git a/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/tests/test_foreign_table_add.py b/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/tests/test_foreign_table_add.py
new file mode 100644
index 000..3f92301
--- /dev/null
+++ b/web/pgadmin/browser/server_groups/servers/databases/schemas/foreign_tables/tests/test_foreign_table_add.py
@@ -0,0 +1,100 @@
+# #
+#
+# pgAdmin 4 - PostgreSQL Tools
+#
+# Copyright (C) 2013 - 2016, The pgAdmin Development Team
+# This software is released under the PostgreSQL Licence
+#
+# ##
+from __future__ import print_function
+import uuid
+import json
+
+from pgadmin.utils.route import BaseTestGenerator
+from pgadmin.browser.server_groups.servers.databases.tests import \
+utils as database_utils
+from pgadmin.browser.server_groups.servers.databases.foreign_data_wrappers.\
+tests import utils as fdw_utils
+from pgadmin.browser.server_groups.servers.databases.foreign_data_wrappers.\
+foreign_servers.tests import utils as fsrv_utils
+from regression import parent_node_dict
+from regression import test_utils as utils
+
+
+class ForeignTableAddTestCase(BaseTestGenerator):
+"""
+This class will add foreign table under database node.
+"""
+
+scenarios = [
+# Fetching default URL for foreign server node.
+('Check foreign table Node', dict(url='/browser/foreign-table/obj/'))
+]
+
+def setUp(self):
+""" This function will create foreign data wrapper and
+foreign server. """
+
+self.schema_data = parent_node_dict['schema'][-1]
+self.server_id = self.schema_data['server_id']
+self.db_id = self.schema_data['db_id']
+self.db_name = parent_node_dict["database"][-1]["db_name"]
+self.schema_name = self.schema_data['schema_name']
+self.schema_id = self.schema_data['schema_id']
+self.fdw_name = "fdw_%s" % (str(uuid.uuid4())[1:4])
+self.fsrv_name = "fsrv_%s" % (str(uuid.uuid4())[1:4])
+self.fdw_id = fdw_utils.create_fdw(self.server, self.db_name,
+ self.fdw_name)
+self.fsrv_id = fsrv_utils.create_fsrv(self.server, self.db_name,
+ self.fsrv_name, self.fdw_name)
+
+def runTest(self):
+"""This function will add foreign table under test database."""
+
+db_con = database_utils.connect_database(self,
+ utils.SERVER_GROUP,
+ self.server_id,
+ self.db_id)
+
+if not db_con["info"] == "Database connected.":
+raise Exception("Could not connect to database.")
+
+fsrv_response = fsrv_utils.verify_fsrv(self.server, self.db_name,
+ self.fsrv_name)
+if not fsrv_response:
+raise Exception("Could not find Foreign Server.")
+
+data = {
+"acl": [],
+"basensp": self.schema_name,
+"columns":
+[
+{
+"attname": "ename",
+"datatype": "text",
+"coloptions": []
+}
+],
+"constraints": [],
+"ftoptions": [],
+"inherits": [],
+"ftsrvname": self.fsrv_name,
+
