On Thu, Dec 16, 2010 at 7:49 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Please note that the SQL scripts seem to be encoded in latin9.
Seems like an odd choice. Why not UTF-8?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 16, 2010 at 7:49 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Please note that the SQL scripts seem to be encoded in latin9.
Seems like an odd choice. Why not UTF-8?
Not a choice, just what's already in…
--
Dimitri Fontaine
On Thu, Dec 16, 2010 at 9:04 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 16, 2010 at 7:49 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Please note that the SQL scripts seem to be encoded in latin9.
Seems like an odd choice.
2010/12/16 Robert Haas robertmh...@gmail.com:
On Thu, Dec 16, 2010 at 7:49 AM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Please note that the SQL scripts seem to be encoded in latin9.
Seems like an odd choice. Why not UTF-8?
Latin 9 = ISO 8859-15 = a more modern version of Latin 1
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 16, 2010 at 9:04 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Please note that the SQL scripts seem to be encoded in latin9.
Seems like an odd choice. Why not UTF-8?
Not a choice, just what's already in
Sure, I get it. I'm
On Dec 16, 2010, at 8:19 AM, Tom Lane wrote:
I would think that we want to establish the same policy as we have for
dictionary files: they're assumed to be UTF-8. I don't believe there
should be an encoding option at all. If we didn't need one for
dictionary files, there is *surely* no
Excerpts from Dimitri Fontaine's message of jue dic 16 09:49:31 -0300 2010:
Hi,
Well $subject says about it all really. The bitrot of course comes from
the fact that the last in-commitfest-dependency has been commited in,
and I kept a version of pg_execute_sql_file() in the extension's
Alvaro Herrera alvhe...@commandprompt.com writes:
I thought the suggestion of having version = 9.1devel line in each
contrib's module extension file was a joke. It is certainly not going
to be sustainable in the long run -- I don't think we want to be
modifying all control files each release.
Alvaro Herrera alvhe...@commandprompt.com writes:
I thought the suggestion of having version = 9.1devel line in each
contrib's module extension file was a joke. It is certainly not going
to be sustainable in the long run -- I don't think we want to be
modifying all control files each release.
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Alvaro Herrera alvhe...@commandprompt.com writes:
I thought the suggestion of having version = 9.1devel line in each
contrib's module extension file was a joke. It is certainly not going
to be sustainable in the long run -- I don't think we want
Tom Lane t...@sss.pgh.pa.us writes:
However, the only way I can see to fix this automatically is to have
the makefiles propagate PG_VERSION_NUM (or one of the other values set
by configure) into generated control files.
Ah, somewhat like what I was asked to remove from the patch, right?
Excerpts from Tom Lane's message of jue dic 16 17:10:10 -0300 2010:
However, the only way I can see to fix this automatically is to have
the makefiles propagate PG_VERSION_NUM (or one of the other values set
by configure) into generated control files. I don't think that's what
we want
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of jue dic 16 17:10:10 -0300 2010:
However, the only way I can see to fix this automatically is to have
the makefiles propagate PG_VERSION_NUM (or one of the other values set
by configure) into generated control
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
However, the only way I can see to fix this automatically is to have
the makefiles propagate PG_VERSION_NUM (or one of the other values set
by configure) into generated control files.
Ah, somewhat like what I
14 matches
Mail list logo
