Re: Patch for DBD::Pg pg_relcheck problem
От | Tom Lane |
---|---|
Тема | Re: Patch for DBD::Pg pg_relcheck problem |
Дата | |
Msg-id | 20819.1039477650@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch for DBD::Pg pg_relcheck problem (Ian Barwick <barwick@gmx.net>) |
Ответы |
Re: Patch for DBD::Pg pg_relcheck problem
|
Список | pgsql-interfaces |
Ian Barwick <barwick@gmx.net> writes: > So out with the candle wax and pins ;-). Am I right > in thinking that the string returned by SELECT version() > starts with the word "PostgreSQL" followed by: > a space; > a single digit indicating the major version number; > a full stop / decimal point; > a single digit indicating the minor version number; > and either "interim release" number (e.g. ".1" in the case of 7.3.1), or > "devel", "rc1" etc. ? I would recommend parsing it the same way pg_dump does, see _check_database_version(). Looks like it's basically skip-11-chars- and-sscanf. Note the lack of assumptions about numbers of digits. In the next protocol version update (hopefully 7.4) I would like to see the basic version string (eg, "7.3.1" or "7.4devel") delivered to the client automatically during connection startup and then available from a libpq inquiry function. This would eliminate the need to call version() explicitly and to know that you must skip "PostgreSQL " in its output. However, it will only help for clients/libraries that are willing to deal exclusively with 7.4-or-newer backends, so it will take a few releases to become really useful. regards, tom lane
В списке pgsql-interfaces по дате отправления: