Re: [GENERAL] Backward compatibility

2017-07-22 Thread Igor Korot
Thx. The split_part() works perfectly. On Sat, Jul 22, 2017 at 10:49 AM, Tom Lane wrote: > Igor Korot writes: >> But it works incorrectly - it should return: >> 9.5.7 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 6.3.1 20161221 >> (Red Hat 6.3.1-1),

Re: [GENERAL] Backward compatibility

2017-07-22 Thread rob stone
On Sat, 2017-07-22 at 10:49 -0400, Tom Lane wrote: > Igor Korot writes: > > But it works incorrectly - it should return: > > 9.5.7 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 6.3.1 > > 20161221 > > (Red Hat 6.3.1-1), 64-bit > > i.e. without the word "PosgreSQL", since

Re: [GENERAL] Backward compatibility

2017-07-22 Thread Tom Lane
Igor Korot writes: > But it works incorrectly - it should return: > 9.5.7 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 6.3.1 20161221 > (Red Hat 6.3.1-1), 64-bit > i.e. without the word "PosgreSQL", since '\s' should match the (first) > space in the version(). position()

Re: [GENERAL] Backward compatibility

2017-07-22 Thread Igor Korot
Hi, John, On Sat, Jul 22, 2017 at 8:44 AM, John McKown wrote: > On Fri, Jul 21, 2017 at 10:21 PM, Igor Korot wrote: >> >> Hi, guys, >> Below query does not even run: >> >> SELECT version(), substring( version() from position( '\s' in version() )

Re: [GENERAL] Backward compatibility

2017-07-22 Thread John McKown
On Fri, Jul 21, 2017 at 10:21 PM, Igor Korot wrote: > Hi, guys, > Below query does not even run: > > SELECT version(), substring( version() from position( '\s' in version() ) > ); > > Could you spot the error? > > ​works for me. psql psql (9.5.7) Type "help" for help.

Re: [GENERAL] Backward compatibility

2017-07-21 Thread Igor Korot
Hi, guys, Below query does not even run: SELECT version(), substring( version() from position( '\s' in version() ) ); Could you spot the error? On Fri, Jul 21, 2017 at 12:11 PM, Igor Korot wrote: > David et al, > > On Fri, Jul 21, 2017 at 12:00 PM, David G. Johnston >

Re: [GENERAL] Backward compatibility

2017-07-21 Thread Igor Korot
David et al, On Fri, Jul 21, 2017 at 12:00 PM, David G. Johnston wrote: > On Fri, Jul 21, 2017 at 8:49 AM, Igor Korot wrote: >> >> MySQL uses this: >> https://dev.mysql.com/doc/refman/5.7/en/mysql-get-server-version.html. >> Is it safe to assume

Re: [GENERAL] Backward compatibility

2017-07-21 Thread David G. Johnston
On Fri, Jul 21, 2017 at 8:49 AM, Igor Korot wrote: > MySQL uses this: > https://dev.mysql.com/doc/refman/5.7/en/mysql-get-server-version.html. > Is it safe to assume that PostgreSQL calculates the version the same way? > ​ Yes and no. Things are changing with this next

Re: [GENERAL] Backward compatibility

2017-07-21 Thread Igor Korot
Hi, guys, On Thu, Jul 20, 2017 at 11:58 PM, Tom Lane wrote: > John R Pierce writes: >> On 7/20/2017 8:40 PM, Tom Lane wrote: >>> Hm, we need to update that text for the new 2-part version numbering >>> scheme, don't we? > >> will 10 return like 100100 if

Re: [GENERAL] Backward compatibility

2017-07-20 Thread Tom Lane
John R Pierce writes: > On 7/20/2017 8:40 PM, Tom Lane wrote: >> Hm, we need to update that text for the new 2-part version numbering >> scheme, don't we? > will 10 return like 100100 if its 10.1, or 11 ? The latter. The two middle digits will be zeroes henceforth,

Re: [GENERAL] Backward compatibility

2017-07-20 Thread John R Pierce
On 7/20/2017 8:40 PM, Tom Lane wrote: Applications might use this function to determine the version of the database server they are connected to. The number is formed by converting the major, minor, and revision numbers into two-decimal-digit numbers and appending them

Re: [GENERAL] Backward compatibility

2017-07-20 Thread Tom Lane
John R Pierce writes: > odds are pretty good that... > |PQserverVersion| > Returns an integer representing the backend version. > int PQserverVersion(const PGconn *conn); > Actually invokes `show server_version_num;' Just for the record, it doesn't invoke that;

Re: [GENERAL] Backward compatibility

2017-07-20 Thread John R Pierce
On 7/20/2017 7:57 PM, David G. Johnston wrote: Actually, The docs do cover how to do this directly in libpq. odds are pretty good that... |PQserverVersion| Returns an integer representing the backend version. int PQserverVersion(const PGconn *conn); Applications

Re: [GENERAL] Backward compatibility

2017-07-20 Thread John R Pierce
On 7/20/2017 7:46 PM, Igor Korot wrote: ALso, I presume there is no special libpg function, right? libpq would only be able to return the libpq version, which might not be the same as the server version. -- john r pierce, recycling bits in santa cruz -- Sent via pgsql-general mailing

Re: [GENERAL] Backward compatibility

2017-07-20 Thread David G. Johnston
On Thursday, July 20, 2017, David G. Johnston wrote: > On Thursday, July 20, 2017, Igor Korot > wrote: > >> Hi, David, >> >> On Thu, Jul 20, 2017 at 10:23 PM, David G. Johnston >>

Re: [GENERAL] Backward compatibility

2017-07-20 Thread David G. Johnston
On Thursday, July 20, 2017, Igor Korot wrote: > Hi, David, > > On Thu, Jul 20, 2017 at 10:23 PM, David G. Johnston > > wrote: > > On Thu, Jul 20, 2017 at 7:13 PM, Igor Korot > wrote: > > >> Is there

Re: [GENERAL] Backward compatibility

2017-07-20 Thread Igor Korot
ALso, I presume there is no special libpg function, right? Thank you. On Thu, Jul 20, 2017 at 10:44 PM, Igor Korot wrote: > Hi, David, > > On Thu, Jul 20, 2017 at 10:23 PM, David G. Johnston > wrote: >> On Thu, Jul 20, 2017 at 7:13 PM, Igor

Re: [GENERAL] Backward compatibility

2017-07-20 Thread Igor Korot
Hi, David, On Thu, Jul 20, 2017 at 10:23 PM, David G. Johnston wrote: > On Thu, Jul 20, 2017 at 7:13 PM, Igor Korot wrote: >> >> Hi, ALL, >> According to the documentation PostgreSQL 9.6 (latest) supports >> >> CREATE INDEX IF NOT EXIST >> >>

Re: [GENERAL] Backward compatibility

2017-07-20 Thread David G. Johnston
On Thu, Jul 20, 2017 at 7:23 PM, Igor Korot wrote: > On Thu, Jul 20, 2017 at 10:19 PM, Andreas Kretschmer > wrote: > > > >>Is there a query or a libpg function which can return the version of > >>the server I'm running? > > > Select version(); > >

Re: [GENERAL] Backward compatibility

2017-07-20 Thread David G. Johnston
On Thu, Jul 20, 2017 at 7:13 PM, Igor Korot wrote: > Hi, ALL, > According to the documentation PostgreSQL 9.6 (latest) supports > > CREATE INDEX IF NOT EXIST > > However, the version 9.4 and below supports only > > CREATE INDEX. > > Is there a query or a libpg function which

Re: [GENERAL] Backward compatibility

2017-07-20 Thread Igor Korot
Hi, guys, On Thu, Jul 20, 2017 at 10:19 PM, Andreas Kretschmer wrote: > On 21 July 2017 04:13:47 GMT+02:00, Igor Korot wrote: >>Hi, ALL, >>According to the documentation PostgreSQL 9.6 (latest) supports >> >>CREATE INDEX IF NOT EXIST >> >>However,

Re: [GENERAL] Backward compatibility

2017-07-20 Thread Andreas Kretschmer
On 21 July 2017 04:13:47 GMT+02:00, Igor Korot wrote: >Hi, ALL, >According to the documentation PostgreSQL 9.6 (latest) supports > >CREATE INDEX IF NOT EXIST > >However, the version 9.4 and below supports only > >CREATE INDEX. > >Is there a query or a libpg function which can

[GENERAL] Backward compatibility

2017-07-20 Thread Igor Korot
Hi, ALL, According to the documentation PostgreSQL 9.6 (latest) supports CREATE INDEX IF NOT EXIST However, the version 9.4 and below supports only CREATE INDEX. Is there a query or a libpg function which can return the version of the server I'm running? And in the latter case - is there a

[GENERAL] Backward Compatibility

2000-11-23 Thread rwk
I have an old Postgres server (v6.3) running on a machine which I do not control and cannot update. I have a new machine which came with Postgres 7.0.2, which I do control. I need to be able to talk to the v6.3 server from the new machine. Can this be done? When I try I get: newMachine$ psql

Re: [GENERAL] Backward Compatibility

2000-11-23 Thread Tom Lane
[EMAIL PROTECTED] writes: I need to be able to talk to the v6.3 server from the new machine. You'll have to install a 6.3.x libpq and psql for that, I'm afraid. regards, tom lane