On 04/02/2015 12:42 PM, Alvaro Herrera wrote:
David Fetter wrote:
I haven't checked yet, but could this be because people aren't using
--enable-depend with ./configure ?
BTW --- No, this can't be the answer; --enable-depend is meant to help
with recompiling after updating the source tree, but
David Fetter wrote:
> I haven't checked yet, but could this be because people aren't using
> --enable-depend with ./configure ?
BTW --- No, this can't be the answer; --enable-depend is meant to help
with recompiling after updating the source tree, but lack of it cannot
cause any failures (assumin
On Thu, Apr 02, 2015 at 11:46:53AM +0900, Michael Paquier wrote:
> On Thu, Apr 2, 2015 at 9:38 AM, Alvaro Herrera
> wrote:
> >
> > David Fetter wrote:
> > > On Wed, Apr 01, 2015 at 08:13:02PM -0300, Alvaro Herrera wrote:
> > > > I have pushed this after some rework. For instance, the 9.0
> > > >
On Thu, Apr 2, 2015 at 9:38 AM, Alvaro Herrera wrote:
>
> David Fetter wrote:
> > On Wed, Apr 01, 2015 at 08:13:02PM -0300, Alvaro Herrera wrote:
> > > I have pushed this after some rework. For instance, the 9.0 and 9.1
> > > versions believed that URIs were accepted, but that stuff was introduce
David Fetter wrote:
> On Wed, Apr 01, 2015 at 08:13:02PM -0300, Alvaro Herrera wrote:
> > I have pushed this after some rework. For instance, the 9.0 and 9.1
> > versions believed that URIs were accepted, but that stuff was introduced
> > in 9.2. I changed some other minor issues -- I hope not to
On Wed, Apr 01, 2015 at 08:13:02PM -0300, Alvaro Herrera wrote:
> I have pushed this after some rework. For instance, the 9.0 and 9.1
> versions believed that URIs were accepted, but that stuff was introduced
> in 9.2. I changed some other minor issues -- I hope not to have broken
> too many othe
I have pushed this after some rework. For instance, the 9.0 and 9.1
versions believed that URIs were accepted, but that stuff was introduced
in 9.2. I changed some other minor issues -- I hope not to have broken
too many other things in the process. Please give the whole thing a
look, preferrabl
On Fri, Feb 27, 2015 at 08:42:29AM -0800, David Fetter wrote:
> On Mon, Feb 23, 2015 at 05:56:12PM -0300, Alvaro Herrera wrote:
> >
> > David Fetter wrote:
> >
> > > My thinking behind this was that the patch is a bug fix and intended
> > > to be back-patched, so I wanted to mess with as little i
On Wed, Mar 4, 2015 at 8:33 AM, David Fetter wrote:
> On Tue, Mar 03, 2015 at 09:52:55PM -0500, Robert Haas wrote:
>> On Mon, Mar 2, 2015 at 5:05 PM, David Fetter wrote:
>> > So just to clarify, are you against back-patching the behavior
>> > change, or the addition to src/common?
>>
>> Mostly th
On Tue, Mar 03, 2015 at 09:52:55PM -0500, Robert Haas wrote:
> On Mon, Mar 2, 2015 at 5:05 PM, David Fetter wrote:
> > So just to clarify, are you against back-patching the behavior
> > change, or the addition to src/common?
>
> Mostly the latter.
So you're saying the former isn't a problem? To
On Mon, Mar 2, 2015 at 5:05 PM, David Fetter wrote:
> So just to clarify, are you against back-patching the behavior change,
> or the addition to src/common?
Mostly the latter.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hacker
David Fetter wrote:
> On Mon, Mar 02, 2015 at 04:52:37PM -0500, Robert Haas wrote:
> > On Mon, Feb 23, 2015 at 3:56 PM, Alvaro Herrera
> > wrote:
> > > David Fetter wrote:
> > >
> > >> My thinking behind this was that the patch is a bug fix and intended
> > >> to be back-patched, so I wanted to me
On Mon, Mar 02, 2015 at 04:52:37PM -0500, Robert Haas wrote:
> On Mon, Feb 23, 2015 at 3:56 PM, Alvaro Herrera
> wrote:
> > David Fetter wrote:
> >
> >> My thinking behind this was that the patch is a bug fix and intended
> >> to be back-patched, so I wanted to mess with as little infrastructure
>
On Mon, Feb 23, 2015 at 3:56 PM, Alvaro Herrera
wrote:
> David Fetter wrote:
>
>> My thinking behind this was that the patch is a bug fix and intended
>> to be back-patched, so I wanted to mess with as little infrastructure
>> as possible. A new version of libpq seems like a very big ask for
>> s
On Fri, Feb 27, 2015 at 02:51:18PM -0300, Alvaro Herrera wrote:
> I don't understand. Why don't these patches move anything to
> src/common?
Because I misunderstood the scope. Hope to get to those this evening.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfe
I don't understand. Why don't these patches move anything to
src/common?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Mon, Feb 23, 2015 at 05:56:12PM -0300, Alvaro Herrera wrote:
>
> David Fetter wrote:
>
> > My thinking behind this was that the patch is a bug fix and intended
> > to be back-patched, so I wanted to mess with as little infrastructure
> > as possible. A new version of libpq seems like a very b
Here's the real attachment. Previous one was a misguided shell
redirection. Meh.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 830d41b9d23716af29491cbab59808c35e25ec12 Mon Sep 17 00:00:00 2001
From: Alvar
David Fetter wrote:
> My thinking behind this was that the patch is a bug fix and intended
> to be back-patched, so I wanted to mess with as little infrastructure
> as possible. A new version of libpq seems like a very big ask for
> such a case. You'll recall that the original problem was that
2015-02-21 7:04 GMT+01:00 Pavel Stehule :
> Hi
>
> 2015-02-20 21:55 GMT+01:00 Alvaro Herrera :
>
>> Pavel Stehule wrote:
>> > 2015-02-20 8:22 GMT+01:00 David Fetter :
>> >
>> > > On Fri, Feb 20, 2015 at 07:10:29AM +0100, Pavel Stehule wrote:
>> > > > Hi
>> > > >
>> > > > I am happy with doc change
2015-02-20 22:25 GMT+01:00 Alvaro Herrera :
> David Fetter wrote:
> > On Fri, Feb 20, 2015 at 05:55:20PM -0300, Alvaro Herrera wrote:
>
> > > Gave this patch a look. In general it looks pretty good, but there is
> > > one troublesome point: it duplicates two functions from libpq into
> psql,
> >
Hi
2015-02-20 21:55 GMT+01:00 Alvaro Herrera :
> Pavel Stehule wrote:
> > 2015-02-20 8:22 GMT+01:00 David Fetter :
> >
> > > On Fri, Feb 20, 2015 at 07:10:29AM +0100, Pavel Stehule wrote:
> > > > Hi
> > > >
> > > > I am happy with doc changes now.
> > > >
> > > > When I test last patch, I found s
David Fetter wrote:
> On Fri, Feb 20, 2015 at 05:55:20PM -0300, Alvaro Herrera wrote:
> > Gave this patch a look. In general it looks pretty good, but there is
> > one troublesome point: it duplicates two functions from libpq into psql,
> > including the URI designators. This doesn't look very n
On Fri, Feb 20, 2015 at 05:55:20PM -0300, Alvaro Herrera wrote:
> Pavel Stehule wrote:
> > 2015-02-20 8:22 GMT+01:00 David Fetter :
> >
> > > On Fri, Feb 20, 2015 at 07:10:29AM +0100, Pavel Stehule wrote:
> > > > Hi
> > > >
> > > > I am happy with doc changes now.
> > > >
> > > > When I test last
Pavel Stehule wrote:
> 2015-02-20 8:22 GMT+01:00 David Fetter :
>
> > On Fri, Feb 20, 2015 at 07:10:29AM +0100, Pavel Stehule wrote:
> > > Hi
> > >
> > > I am happy with doc changes now.
> > >
> > > When I test last patch, I found sigfault bug, because host =
> > > PQhost(o_conn); returns NULL. I
2015-02-20 8:22 GMT+01:00 David Fetter :
> On Fri, Feb 20, 2015 at 07:10:29AM +0100, Pavel Stehule wrote:
> > Hi
> >
> > I am happy with doc changes now.
> >
> > When I test last patch, I found sigfault bug, because host =
> > PQhost(o_conn); returns NULL. I fexed it - please, see patch 007
> >
>
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
no issues with last 007 patch
--
Sent via pgsql-hackers ma
On Fri, Feb 20, 2015 at 07:10:29AM +0100, Pavel Stehule wrote:
> Hi
>
> I am happy with doc changes now.
>
> When I test last patch, I found sigfault bug, because host =
> PQhost(o_conn); returns NULL. I fexed it - please, see patch 007
>
> If you are agree with fix, I'll mark this patch as read
Hi
I am happy with doc changes now.
When I test last patch, I found sigfault bug, because host =
PQhost(o_conn); returns NULL. I fexed it - please, see patch 007
If you are agree with fix, I'll mark this patch as ready for commit.
Regards
Pavel
2015-02-19 23:33 GMT+01:00 David Fetter :
> On
On Thu, Feb 19, 2015 at 09:32:29PM +0100, Pavel Stehule wrote:
> 2015-02-19 19:51 GMT+01:00 David Fetter :
>
> > On Sun, Feb 01, 2015 at 08:38:24AM +0100, Pavel Stehule wrote:
> >
> > I'm not sure how best to illustrate those. Are you thinking of one
> > example each for the URI and conninfo case
2015-02-19 19:51 GMT+01:00 David Fetter :
> On Sun, Feb 01, 2015 at 08:38:24AM +0100, Pavel Stehule wrote:
> > Hi all
> >
> > I am sending a review of this patch:
> >
> > * What it does? - Allow to connect to other db by \connect uri connection
> > format
> >
> > postgres=# \c postgresql://localho
On Sun, Feb 01, 2015 at 08:38:24AM +0100, Pavel Stehule wrote:
> Hi all
>
> I am sending a review of this patch:
>
> * What it does? - Allow to connect to other db by \connect uri connection
> format
>
> postgres=# \c postgresql://localhost?service=old
> psql (9.5devel, server 9.2.9)
> You are n
Hi all
I am sending a review of this patch:
* What it does? - Allow to connect to other db by \connect uri connection
format
postgres=# \c postgresql://localhost?service=old
psql (9.5devel, server 9.2.9)
You are now connected to database "postgres" as user "pavel".
* Would we this feature? - ye
On Sat, Jan 10, 2015 at 04:41:16PM -0800, David Fetter wrote:
> On Sat, Jan 10, 2015 at 09:30:57AM +0100, Erik Rijkers wrote:
> > On Fri, January 9, 2015 20:15, David Fetter wrote:
> > > [psql_fix_uri_service_003.patch]
> >
> > Applies on master; the feature (switching services) works well but a \
On Sat, Jan 10, 2015 at 09:30:57AM +0100, Erik Rijkers wrote:
> On Fri, January 9, 2015 20:15, David Fetter wrote:
> > [psql_fix_uri_service_003.patch]
>
> Applies on master; the feature (switching services) works well but a \c
> without any parameters produces a segfault:
>
> (centos 6.6, 4.9.2
On 2015-01-10 09:49:52 -0500, Andrew Dunstan wrote:
> >Save static inline functions, that is.
>
> Yeah, but not normally data items. (I did say "in general"). As a general
> rule for novice C programmers I think my rule of thumb is reasonable.
Agreed. I just tried to preempt somebody grepping for
On 01/10/2015 09:32 AM, Andres Freund wrote:
On 2015-01-10 09:16:07 -0500, Andrew Dunstan wrote:
+static const char uri_designator[] = "postgresql://";
+static const char short_uri_designator[] = "postgres://";
These declarations in common.h would cause a separate instance of these
pie
On 2015-01-10 09:16:07 -0500, Andrew Dunstan wrote:
>+static const char uri_designator[] = "postgresql://";
>+static const char short_uri_designator[] = "postgres://";
>
> These declarations in common.h would cause a separate instance of these
> pieces of storage to occur in every object f
On 01/09/2015 02:15 PM, David Fetter wrote:
Some C cleanups...
Not quite enough cleanup. As I told you on IRC, the only addition to
common.h should be the declaration of recognized_connection_string.
These do not belong there (they belong in common.c):
+static const char uri_designa
On Fri, January 9, 2015 20:15, David Fetter wrote:
> [psql_fix_uri_service_003.patch]
Applies on master; the feature (switching services) works well but a \c without
any parameters produces a segfault:
(centos 6.6, 4.9.2, 64-bit)
$ echo -en "$PGSERVICEFILE\n$PGSERVICE\n$PGPORT\n"
/home/aardvar
On Thu, Jan 08, 2015 at 08:04:47PM -0800, David Fetter wrote:
> On Mon, Jan 05, 2015 at 02:26:59PM -0800, David Fetter wrote:
> > On Tue, Dec 30, 2014 at 04:48:11PM -0800, David Fetter wrote:
> > > On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:
> > > >
> > > > Yeah, that's the cor
On Mon, Jan 05, 2015 at 02:26:59PM -0800, David Fetter wrote:
> On Tue, Dec 30, 2014 at 04:48:11PM -0800, David Fetter wrote:
> > On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:
> > >
> > > Yeah, that's the correct solution. It should not be terribly difficult to
> > > create a tes
On Tue, Dec 30, 2014 at 04:48:11PM -0800, David Fetter wrote:
> On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:
> >
> > Yeah, that's the correct solution. It should not be terribly difficult to
> > create a test for a conninfo string in the dbname parameter. That's what
> > libpq d
On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:
>
> On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:
> >On 12/17/2014 10:03 AM, Albe Laurenz wrote:
> >>David Fetter wrote:
> >>>I've noticed that psql's \c function handles service= requests in a
> >>>way that I can only characteri
On Fri, Dec 19, 2014 at 07:03:36PM -0700, David Johnston wrote:
> On Wed, Dec 17, 2014 at 8:25 AM, David Fetter [via PostgreSQL] <
> ml-node+s1045698n5831124...@n5.nabble.com> wrote:
>
> > On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:
> >
> > >
> > > On 12/17/2014 04:11 AM, Heikk
On Wed, Dec 17, 2014 at 8:25 AM, David Fetter [via PostgreSQL] <
ml-node+s1045698n5831124...@n5.nabble.com> wrote:
> On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:
>
> >
> > On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:
> > >On 12/17/2014 10:03 AM, Albe Laurenz wrote:
> > >>Da
On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:
>
> On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:
> >On 12/17/2014 10:03 AM, Albe Laurenz wrote:
> >>David Fetter wrote:
> >>>I've noticed that psql's \c function handles service= requests in a
> >>>way that I can only characteri
On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:
On 12/17/2014 10:03 AM, Albe Laurenz wrote:
David Fetter wrote:
I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.
This came up in the context of connecting to a cloud hosting servi
On 12/17/2014 10:03 AM, Albe Laurenz wrote:
David Fetter wrote:
I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.
This came up in the context of connecting to a cloud hosting service
named after warriors or a river or something, who
David Fetter wrote:
> I've noticed that psql's \c function handles service= requests in a
> way that I can only characterize as broken.
>
> This came up in the context of connecting to a cloud hosting service
> named after warriors or a river or something, whose default hostnames
> are long, conf
I do indeed see this behavior in some very quick testing using 9.3
David Fetter wrote
> I've noticed that psql's \c function handles service= requests in a
> way that I can only characterize as broken.
Looking at the docs the fact it attempts to treat "service=foo" as anything
other than a data
Folks,
I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.
This came up in the context of connecting to a cloud hosting service
named after warriors or a river or something, whose default hostnames
are long, confusing, and easy to typo,
52 matches
Mail list logo
