Re: [PyGreSQL] Timeframe for 5.2 or 5.1.3 release

[Christoph Zwerschke]

Am 20.06.2020 um 15:58 schrieb Justin Pryzby:

I think you could have just as well said the opposite (passing the
column names in the unesaped table names was a bad idea), since I was
on the verge of suggesting we just do document that :)

Right, you can argue that the feature existed all the time already :)

Will fix the typo and then have a look at #29.

-- Christoph
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql

Re: [PyGreSQL] Timeframe for 5.2 or 5.1.3 release

[Justin Pryzby]

On Sat, Jun 20, 2020 at 03:10:02PM +0200, Christoph Zwerschke wrote:
> Am 20.06.2020 um 04:02 schrieb Justin Pryzby:
> > I'm attaching my WIP patch.  It will needs to be cleaned up, since (1) and 
> > (2)
> > will surely cause rebase conflicts, so this is just a POC.
> 
> Thank you. I have commited this after making a few amendments:
> https://github.com/PyGreSQL/PyGreSQL/commit/f82d4cd20dfa66ec791091581e60e299b329c70e

Thank you

 ``columns`` is a optional sequence of column names to be passed on 

=> *an* optional

> This works with Python 2 and 3 now (we will drop Python 2 support probably
> in version 6, but for now we must stay compatible).
> 
> Escaping the table and column names was a
> good idea (you must free the space for the escaped name though).

I think you could have just as well said the opposite (passing the column names
in the unesaped table names was a bad idea), since I was on the verge of
suggesting we just do document that :)

> Does my commit cover everything you mentioned, can we close the issue?

I think it's done - thanks for finishing it.

-- 
Justin
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql

Re: [PyGreSQL] Timeframe for 5.2 or 5.1.3 release

[Christoph Zwerschke]

Am 20.06.2020 um 04:02 schrieb Justin Pryzby:

I'm attaching my WIP patch.  It will needs to be cleaned up, since (1) and (2)
will surely cause rebase conflicts, so this is just a POC.


Thank you. I have commited this after making a few amendments:

https://github.com/PyGreSQL/PyGreSQL/commit/f82d4cd20dfa66ec791091581e60e299b329c70e

This works with Python 2 and 3 now (we will drop Python 2 support 
probably in version 6, but for now we must stay compatible).


I have also added some more tests. Escaping the table and column names 
was a good idea (you must free the space for the escaped name though).


Does my commit cover everything you mentioned, can we close the issue?

-- Christoph
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql

Re: [PyGreSQL] Timeframe for 5.2 or 5.1.3 release

[Justin Pryzby]

On Sat, Jun 20, 2020 at 01:10:14AM +0200, Christoph Zwerschke wrote:
> Am 20.06.2020 um 00:54 schrieb Justin Pryzby:
> > I think these would be easy to add.
> > 
> > https://github.com/PyGreSQL/PyGreSQL/issues/29
> > The pgquery type should have a method listtypes() #29
> > I sent a patch for this to the list last year
> > 
> > https://github.com/PyGreSQL/PyGreSQL/issues/24
> > Allow inserttable() to take columns as parameter #24
> > This is simple enough I can probably put something together
> 
> Ok, I will look into these two issues tomorrow.

1) This is actually possible if one passes a column list in the "table"
argument:
|d.inserttable('t(j)', ([2],))
This works by abusing the "table" argument, which isn't being escaped - That
should be addressed in a separate commit.

2) I think these should all be factored out of all their callers in the C
module: PyBytes_FromStringAndSize() / get_decoded_string().

3) I implemented an interface like:
|d.inserttable('t', ([2],), ['col1', 'col2'])
I'm attaching my WIP patch.  It will needs to be cleaned up, since (1) and (2)
will surely cause rebase conflicts, so this is just a POC.

4) Note that this changelog item is under PGDB but should be under PG:
"The `types` parameter of `format_query` can now be passed as a string..."

-- 
Justin
>From 1dfd3ba134d43f3464ddee4b4cde37e06af2acb7 Mon Sep 17 00:00:00 2001
From: Justin Pryzby 
Date: Fri, 19 Jun 2020 19:51:58 -0500
Subject: [PATCH] WIP/POC: add an argument to inserttable() accepting optional
 list of column names

---
 docs/contents/changelog.rst  | 10 ---
 docs/contents/pg/connection.rst  |  4 ++-
 pgconn.c | 51 
 tests/test_classic_connection.py | 13 
 4 files changed, 67 insertions(+), 11 deletions(-)

diff --git a/docs/contents/changelog.rst b/docs/contents/changelog.rst
index eaafb88..b821a89 100644
--- a/docs/contents/changelog.rst
+++ b/docs/contents/changelog.rst
@@ -14,16 +14,18 @@ Version 5.2 (to be released)
   Additional connection parameter ``nowait``, and connection methods
   `send_query()`, `poll()`, `set_non_blocking()`, `is_non_blocking()`.
   Generously contributed by Patrick TJ McPhee (#19).
+- The `types` parameter of `format_query` can now be passed as a string
+  that will be split on whitespace when values are passed as a sequence,
+  and the types can now also be specified using actual Python types
+  instead of type names. Suggested by Justin Pryzby (#38).
+- The `inserttable()` now accepts an optional column list to be passed on
+  to the underlying SQL ``COPY`` command.
 
 - Changes to the DB-API 2 module (pgdb):
 - When using Python 2, errors are now derived from StandardError
   instead of Exception, as required by the DB-API 2 compliance test.
 - Connection arguments containing single quotes caused problems
   (reported and fixed by Tyler Ramer and Jamie McAtamney).
-- The `types` parameter of `format_query` can now be passed as a string
-  that will be split on whitespace when values are passed as a sequence,
-  and the types can now also be specified using actual Python types
-  instead of type names. Suggested by Justin Pryzby (#38).
 
 Version 5.1.2 (2020-04-19)
 --
diff --git a/docs/contents/pg/connection.rst b/docs/contents/pg/connection.rst
index f342c02..acf477c 100644
--- a/docs/contents/pg/connection.rst
+++ b/docs/contents/pg/connection.rst
@@ -487,12 +487,13 @@ first, otherwise :meth:`Connection.getnotify` will always return ``None``.
 inserttable -- insert a list into a table
 -
 
-.. method:: Connection.inserttable(table, values)
+.. method:: Connection.inserttable(table, values, [columns])
 
 Insert a Python list into a database table
 
 :param str table: the table name
 :param list values: list of rows values
+:param list columns: list of column names
 :rtype: None
 :raises TypeError: invalid connection, bad argument type, or too many arguments
 :raises MemoryError: insert buffer could not be allocated
@@ -503,6 +504,7 @@ It inserts the whole values list into the given table. Internally, it
 uses the COPY command of the PostgreSQL database. The list is a list
 of tuples/lists that define the values for each inserted row. The rows
 values may contain string, integer, long or double (real) values.
+columns is an iterable over column names to be passed to the ``COPY`` command.
 
 .. warning::
 
diff --git a/pgconn.c b/pgconn.c
index f8c81e2..b7452e4 100644
--- a/pgconn.c
+++ b/pgconn.c
@@ -686,13 +686,14 @@ conn_is_non_blocking(connObject *self, PyObject *args)
 
 /* Insert table */
 static char conn_inserttable__doc__[] =
-"inserttable(table, data) -- insert list into table\n\n"
-"The fields in the list must be in the same order as in the table.\n";
+"inserttable(table, data, [columns]) -- insert list into table\n\n"
+"The fields in the list 

Re: [PyGreSQL] Timeframe for 5.2 or 5.1.3 release

[Christoph Zwerschke]

Am 20.06.2020 um 00:54 schrieb Justin Pryzby:

I think these would be easy to add.

https://github.com/PyGreSQL/PyGreSQL/issues/29
The pgquery type should have a method listtypes() #29
I sent a patch for this to the list last year

https://github.com/PyGreSQL/PyGreSQL/issues/24
Allow inserttable() to take columns as parameter #24
This is simple enough I can probably put something together


Ok, I will look into these two issues tomorrow.

-- Christoph
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql

Re: [PyGreSQL] Timeframe for 5.2 or 5.1.3 release

[Justin Pryzby]

On Sat, Jun 20, 2020 at 12:43:23AM +0200, Christoph Zwerschke wrote:
> My plan is now to release version 5.2 tomorrow. Are there some things that I
> should still consider for the release? Then please let me know.

I think these would be easy to add.

https://github.com/PyGreSQL/PyGreSQL/issues/29
The pgquery type should have a method listtypes() #29 
I sent a patch for this to the list last year

https://github.com/PyGreSQL/PyGreSQL/issues/24
Allow inserttable() to take columns as parameter #24 
This is simple enough I can probably put something together

-- 
Justin
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql

Re: [PyGreSQL] Timeframe for 5.2 or 5.1.3 release

[Christoph Zwerschke]

My plan is now to release version 5.2 tomorrow. Are there some things 
that I should still consider for the release? Then please let me know.


As a new feature, I have included support for asynchronous processing, 
which was suggested on this mailing list quite a while ago. The feature 
is still experimental and only rudimentarily tested, but I think we can 
stabilize this in patch releases instead of creating beta releases, 
since the rest of the package should be stable.


-- Christoph



Am 15.06.2020 um 19:51 schrieb Tyler Ramer:

Hi,

We recently submitted a patch, 
https://github.com/PyGreSQL/PyGreSQL/commit/b1e040e989b5b1b75f42c1103562bfe8f09f93c3*, 
* to the pygresql source.


We were wondering what the timeframe might be to getting this fix in a 
versioned release available on PyPi, as part of 5.2 or 5.1.3 or so.


Thanks much!

Tyler Ramer  |  Software Engineer, Tanzu Data |tra...@vmware.com 



___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql

___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql

Re: [PyGreSQL] Timeframe for 5.2 or 5.1.3 release

[Christoph Zwerschke]

I plan to work on PyGreSQL this week and will probably also cut a new 
release then. If there are any other fixes you want to get into the 
release, please open issues on GitHub.


-- Christoph


Am 15.06.2020 um 19:51 schrieb Tyler Ramer:

Hi,

We recently submitted a patch, 
https://github.com/PyGreSQL/PyGreSQL/commit/b1e040e989b5b1b75f42c1103562bfe8f09f93c3*, 
* to the pygresql source.


We were wondering what the timeframe might be to getting this fix in a 
versioned release available on PyPi, as part of 5.2 or 5.1.3 or so.


Thanks much!

Tyler Ramer  |  Software Engineer, Tanzu Data |tra...@vmware.com 



___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql


___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql

[PyGreSQL] Timeframe for 5.2 or 5.1.3 release

[Tyler Ramer]

Hi,

We recently submitted a patch, 
https://github.com/PyGreSQL/PyGreSQL/commit/b1e040e989b5b1b75f42c1103562bfe8f09f93c3,
  to the pygresql source.

We were wondering what the timeframe might be to getting this fix in a 
versioned release available on PyPi, as part of 5.2 or 5.1.3 or so.

Thanks much!

Tyler Ramer  |  Software Engineer, Tanzu Data | 
tra...@vmware.com
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql