On 29 August 2016 at 11:46, Andres Freund wrote:
> On 2016-08-29 11:41:00 +0800, Craig Ringer wrote:
>> On 29 August 2016 at 02:52, Tom Lane wrote:
>> > "Regina Obe" writes:
>> >> The routine in PostGIS to parse out the version number from pg_config is
>> >> breaking in the 10 cycle
>> >
>> > TB
On 2016-08-29 11:41:00 +0800, Craig Ringer wrote:
> On 29 August 2016 at 02:52, Tom Lane wrote:
> > "Regina Obe" writes:
> >> The routine in PostGIS to parse out the version number from pg_config is
> >> breaking in the 10 cycle
> >
> > TBH, I wonder why you are doing that in the first place; it
On 29 August 2016 at 02:52, Tom Lane wrote:
> "Regina Obe" writes:
>> The routine in PostGIS to parse out the version number from pg_config is
>> breaking in the 10 cycle
>
> TBH, I wonder why you are doing that in the first place; it does not
> seem like the most reliable source of version infor
"Regina Obe" writes:
> The routine in PostGIS to parse out the version number from pg_config is
> breaking in the 10 cycle
TBH, I wonder why you are doing that in the first place; it does not
seem like the most reliable source of version information. If you
need to do compile-time tests, PG_CATA
On 08/28/2016 09:55 AM, Regina Obe wrote:
> The routine in PostGIS to parse out the version number from pg_config is
> breaking in the 10 cycle.
>
> Issue seems to be because there is no minor specified.
>
> e.g.
>
> pgconfig --version
>
> returns:
>
> PostgreSQL 10devel
>
> Instead of expec
The routine in PostGIS to parse out the version number from pg_config is
breaking in the 10 cycle.
Issue seems to be because there is no minor specified.
e.g.
pgconfig --version
returns:
PostgreSQL 10devel
Instead of expected
PostgreSQL 10.0devel
Is this the way it's going to be or will th
