On Sat, Mar 28, 2020 at 07:14:23PM +0100, Christoph Zwerschke wrote:
> Am 28.03.2020 um 18:56 schrieb Justin Pryzby:
> > Maybe that should be --with-ssl-info ? I found this:
>
> Not sure about that. In the context of setup.py and negative_opt, I only see
> the 'no-' pattern being followed. Also,
Am 28.03.2020 um 18:56 schrieb Justin Pryzby:
> Maybe that should be --with-ssl-info ? I found this:
Not sure about that. In the context of setup.py and negative_opt, I only
see the 'no-' pattern being followed. Also, this is backward compatible.
-- Christoph
On Sat, Mar 28, 2020 at 06:24:12PM +0100, Christoph Zwerschke wrote:
> Am 28.03.2020 um 16:21 schrieb Justin Pryzby:
> > Also, you have every option defaulting to try, with the only consequence of
> > an
> > unsupported PG version being a warning. I mentioned that packages (at
> > least in
> >
Am 28.03.2020 um 16:21 schrieb Justin Pryzby:
Also, you have every option defaulting to try, with the only consequence of an
unsupported PG version being a warning. I mentioned that packages (at least in
the past for Debian) were encouraged to compile with --enable-foo --enable-bar..
..such
On Sat, Mar 28, 2020 at 03:50:57PM +0100, Christoph Zwerschke wrote:
> Ok, I found that distutils even has a way to define "negative" options and
> used it in setup.py now:
>
> Please have a look at:
> https://github.com/PyGreSQL/PyGreSQL/commit/4b88231afd6bdfb40dca20780cdf006fe2346ea8
+
Ok, I found that distutils even has a way to define "negative" options
and used it in setup.py now:
Please have a look at:
https://github.com/PyGreSQL/PyGreSQL/commit/4b88231afd6bdfb40dca20780cdf006fe2346ea8
Let me know what you think about this change.
-- Christoph
Am 25.03.2020 um 12:28 schrieb Justin Pryzby:
I think (1) is more common, I think that's what autoconf and gnu
tools use.
In that case, maybe we should use enable/disable or with/without as
prefixes, like autotools? But I think it's not very common as setup
option. Also, by using the old
On Wed, Mar 25, 2020 at 12:25:12PM +0100, Christoph Zwerschke wrote:
> Am 25.03.2020 um 10:34 schrieb Justin Pryzby:
> > I think I would leave the "positive" variable names, and *add* negative
> > forms
> > of the commandline options. --no-foo and/or --foo=no
>
> 1) Either two options
Am 25.03.2020 um 10:34 schrieb Justin Pryzby:
I think I would leave the "positive" variable names, and *add* negative forms
of the commandline options. --no-foo and/or --foo=no
Yes, that would be nice. Unfortunately, the options are not interpreted
by us, but by distutils. The way the
On Wed, Mar 25, 2020 at 10:08:25AM +0100, Christoph Zwerschke wrote:
>
> Am 25.03.2020 um 02:20 schrieb Justin Pryzby:
> > The old stuff can be removed eventually. I like this:
> >
> > if self.escaping_funcs and pg_version >= (9, 0):
> >
Am 25.03.2020 um 02:20 schrieb Justin Pryzby:
> The old stuff can be removed eventually. I like this:
>
> if self.escaping_funcs and pg_version >= (9, 0):
> define_macros.append(('ESCAPING_FUNCS', None))
> That allows a packager to disable a feature
> if they want the
On Tue, Mar 24, 2020 at 09:10:18AM +0100, Christoph Zwerschke wrote:
> Maybe where we release binaries (currently only for Windows) we could ship
> them with a matching libql dll that will be installed with Pip alongside the
> PyGres dll?
I thinnk that would require the windows version of rpath
Am 24.03.2020 um 05:46 schrieb Justin Pryzby:
This patch got stuck due to our limited understand of python's
dynamic loading of shared libraries. I picked it up again ince I
have some downtime..
Thanks for working on this problem. Would be great if we could resolve
it. Otherwise it always
This patch got stuck due to our limited understand of python's dynamic loading
of shared libraries. I picked it up again ince I have some downtime..
I think that way it's supposed to work, for an OS distribution, is that, at
compile time, whatever library is linked to, its SONAME is used, but
Am 06.10.2019 um 21:39 schrieb Justin Pryzby:
> That doesn't explain it :(
>
> Find attached t.c building t.so...
Thanks. At least we have ruled that out :/
Winter is coming and maybe we can find some rainy weekend to investigate
deeper and learn a thing or two about the sacred science of
On Sun, Oct 06, 2019 at 05:57:38PM +0200, Christoph Zwerschke wrote:
> Am 06.10.2019 um 15:20 schrieb Justin Pryzby:
> > Remember, lazy binding is the default on my machine, and my patch
> > doesn't DWIW here.. So I don't think adding lazy link options
> > is going to help. I think because of
Am 06.10.2019 um 15:20 schrieb Justin Pryzby:
> Remember, lazy binding is the default on my machine, and my patch
> doesn't DWIW here.. So I don't think adding lazy link options
> is going to help. I think because of something python is doing (??)
Another difference is that in your example
On Sun, Oct 06, 2019 at 01:03:21PM +0200, Christoph Zwerschke wrote:
> Am 06.10.2019 um 01:15 schrieb Justin Pryzby:
> >On Sat, Oct 05, 2019 at 11:43:23PM +0200, Christoph Zwerschke wrote:
> >..but I don't think it's a solution for pygres ? I tried it and still get a
> >symbol resolution error.
Am 06.10.2019 um 01:15 schrieb Justin Pryzby:
On Sat, Oct 05, 2019 at 11:43:23PM +0200, Christoph Zwerschke wrote:
..but I don't think it's a solution for pygres ? I tried it and still get a
symbol resolution error. So, unless someone knows or finds better, it means
there's nothing stopping
On Sat, Oct 05, 2019 at 11:43:23PM +0200, Christoph Zwerschke wrote:
> Am 05.10.2019 um 23:10 schrieb Christoph Zwerschke:
> >Just tried what you did with that t.c program, but strangely I get the
> >"undefined symbol" error when I downgrade libpq and run "./t 0", even when
> >LD_BIND_NOW is not
Am 05.10.2019 um 23:33 schrieb Justin Pryzby:
> You probably realized that my email failed to show that I
> downgraded libpq between invocacations of "PGDATABASE=postgres ./t 1"
Yes, I understood what you were doing. But I could only reproduce it
when adding the "-Wl,-z,lazy" option. Not sure
Am 05.10.2019 um 23:10 schrieb Christoph Zwerschke:
Just tried what you did with that t.c program, but strangely I get the
"undefined symbol" error when I downgrade libpq and run "./t 0", even
when LD_BIND_NOW is not defined. I am using Ubuntu instead of Debian,
but that shouldn't matter.
On Sat, Oct 05, 2019 at 07:47:50PM +0200, Christoph Zwerschke wrote:
>
> Am 05.10.2019 um 18:47 schrieb Justin Pryzby:
> > On Sat, Oct 05, 2019 at 06:37:36PM +0200, Christoph Zwerschke wrote:
> >> Are you sure you compiled that with the pgconfig.h of Postgres 12?
> >> setup.py is using the
Am 05.10.2019 um 18:47 schrieb Justin Pryzby:
> On Sat, Oct 05, 2019 at 06:37:36PM +0200, Christoph Zwerschke wrote:
>> Are you sure you compiled that with the pgconfig.h of Postgres 12?
>> setup.py is using the includes specified by the pgconfig tool.
> The intended behavior is to hit the
Am 05.10.2019 um 18:04 schrieb Justin Pryzby:
On Sat, Oct 05, 2019 at 04:48:40PM +0200, Christoph Zwerschke wrote:
Find attached minimal patch.
Thank you, looks fine. I've already added docs and tests as well, but not
yet committed to trunk.
I didn't mean you had to stop and do that - I
On Sat, Oct 05, 2019 at 04:48:40PM +0200, Christoph Zwerschke wrote:
> >Find attached minimal patch.
>
> Thank you, looks fine. I've already added docs and tests as well, but not
> yet committed to trunk.
I didn't mean you had to stop and do that - I hammered it out while waiting for
Am 05.10.2019 um 02:07 schrieb Justin Pryzby:
On Wed, May 15, 2019 at 08:44:49AM -0500, Justin Pryzby wrote:
Also, as of PG12 (unreleased), there'll be this new interface:
https://www.postgresql.org/docs/devel/release-12.html#id-1.3.7
|Add libpq function to report the memory size of the query
On Wed, May 15, 2019 at 08:44:49AM -0500, Justin Pryzby wrote:
> Also, as of PG12 (unreleased), there'll be this new interface:
> https://www.postgresql.org/docs/devel/release-12.html#id-1.3.7
> |Add libpq function to report the memory size of the query result (Lars
> Kanis, Tom Lane)
> |The
28 matches
Mail list logo
