Re: [HACKERS] Documentation for temp_file_limit
On fre, 2012-05-04 at 22:25 -0400, Bruce Momjian wrote: > The new 9.2 GUC parameter temp_file_limit says it restricts temporary > file usage per session, but it doesn't say what happens if a session > needs to exceed that value --- it throws an error. Shouldn't we mention > that? Yes, that would be useful. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove dead ports?
On fre, 2012-05-04 at 18:16 -0400, Bruce Momjian wrote: > Not sure where you got 24 hours: > > Tues http://archives.postgresql.org/pgsql-hackers/2012-05/msg00061.php > Wed http://archives.postgresql.org/pgsql-general/2012-05/msg00060.php > Thur http://archives.postgresql.org/pgsql-committers/2012-05/msg00023.php The time between the post to -general and the commit. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove dead ports?
On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote: > What's the grounds for asserting they were known not to work? Not > actual testing, I assume. There were either essential pieces missing (e.g., no shared library support, or no Makefile.port), or we had received reports in the past the platform doesn't work and won't be fixed anymore by the original supporter. > Furthermore, I would want to insist that a complainer provide a > buildfarm member as the price of us continuing to support an old > uncommon platform. Otherwise the apparent support is hollow. The BSDI > port was viable for us to support as long as Bruce was using it daily, > but with that gone, we need somebody else to be testing it. Based on these emerging criteria, should we also remove the other platforms on my original "marginal" list? irix osf sco irix and osf support was already dropped in Python 3.0, so probably their time is up. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
On fre, 2012-05-04 at 13:43 -0400, Robert Haas wrote: > For this particular case, I think you just need some place to store a > pg_type -> pg_proc mapping. I'm not exactly sure how to make that not > a JSON-specific hack, since I certainly don't think we'd want to add a > new catalog just for that. I think you're thinking of pg_cast. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
On fre, 2012-05-04 at 12:30 -0400, Andrew Dunstan wrote: > Yeah, what I've been thinking about in conjunction with similar > problems is some sort of type registry, so that we could code for > non-builtin types in certain cases. It certainly seems to come up a lot, but I'm not sure whether the two main use cases -- mapping types into languages, and mapping types into JSON (or XML, as an alternative) -- would have the same solution. A third use case that could be included as well is changing the main text or binary format of a type (e.g., what datestyle does). So instead of having just a hard-coded set of typinput/typoutput, typrecv/typsend, you'd have a catalog of (context, inputfunc, outputfunc) and the context would a language, something json or xml, or a user-settable value. This could become quite complicated, but it sure could solve a lot of issues in one go. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
On fre, 2012-05-04 at 15:59 -0400, Robert Haas wrote: > > Can we at least have the xxx_to_json() functions try cast to json > first > > and fall back to text if the cast fails. > > I think the idea that you can involve the casting machinery in this is > misguided. sometextval::json has got to mean that sometextval is > expected to be in the form of a syntactically correct JSON value - and > NOT that we wrap it in a JSON string. I think it's only wrong if you try casting first and fall back to text. Otherwise it could work, if the set of all json casts is defined consistently. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove dead ports?
On Sat, May 05, 2012 at 11:59:54AM +0300, Peter Eisentraut wrote: > On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote: > > What's the grounds for asserting they were known not to work? Not > > actual testing, I assume. > > There were either essential pieces missing (e.g., no shared library > support, or no Makefile.port), or we had received reports in the past > the platform doesn't work and won't be fixed anymore by the original > supporter. > > > Furthermore, I would want to insist that a complainer provide a > > buildfarm member as the price of us continuing to support an old > > uncommon platform. Otherwise the apparent support is hollow. The BSDI > > port was viable for us to support as long as Bruce was using it daily, > > but with that gone, we need somebody else to be testing it. > > Based on these emerging criteria, should we also remove the other > platforms on my original "marginal" list? > > irix > osf > sco > > irix and osf support was already dropped in Python 3.0, so probably > their time is up. Good question. SCO seems risky, but irix and osf are very possible. I would ask about all three on general. You probably have to give it more time because we don't know as much about the usage as we did about bsdi. We have to wrap this up before beta so it will be tight. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Uppercase tab completion keywords in psql?
On Fri, May 04, 2012 at 08:46:28PM +0300, Peter Eisentraut wrote: > On tor, 2012-05-03 at 15:47 -0400, Bruce Momjian wrote: > > Peter, where are we on this? > > I hadn't received any clear feedback, but if no one objects, I can > commit it. I think there were enough people that wanted some kind of control in this area. I did give you feedback on the patch. --- > > > > On Fri, Mar 30, 2012 at 08:16:59PM +0300, Peter Eisentraut wrote: > > > On fre, 2012-03-23 at 07:52 -0700, David Fetter wrote: > > > > On Thu, Mar 22, 2012 at 06:05:30PM -0400, Andrew Dunstan wrote: > > > > > On 03/22/2012 05:49 PM, Bruce Momjian wrote: > > > > > >Robert Haas and I are disappointed by this change. I liked the > > > > > >fact that I could post nice-looking SQL queries without having to > > > > > >use my capslock key (which I use as a second control key). Any > > > > > >chance of reverting this change? > > > > > > > > > > > > > > > > Should it be governed by a setting? > > > > > > > > Something like (upper|lower|preserve) ? > > > > > > How about this patch then? (There are actually four possible settings, > > > see patch.) > > -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
On Sat, 2012-05-05 at 12:16 +0300, Peter Eisentraut wrote: > On fre, 2012-05-04 at 15:59 -0400, Robert Haas wrote: > > > Can we at least have the xxx_to_json() functions try cast to json > > first > > > and fall back to text if the cast fails. > > > > I think the idea that you can involve the casting machinery in this is > > misguided. sometextval::json has got to mean that sometextval is > > expected to be in the form of a syntactically correct JSON value - and > > NOT that we wrap it in a JSON string. > > I think it's only wrong if you try casting first and fall back to text. > Otherwise it could work, if the set of all json casts is defined > consistently. Currently the default "cast" for non-number, non-bool, not-already-json, non-null values is to wrap text representation in double quotes. So casting first then fall back to _quoted_ text is wrong only for those types which have a very ugly text representation :) -- --- Hannu Krosing PostgreSQL Unlimited Scalability and Performance Consultant 2ndQuadrant Nordic PG Admin Book: http://www.2ndQuadrant.com/books/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove dead ports?
Peter Eisentraut writes: > On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote: >> Furthermore, I would want to insist that a complainer provide a >> buildfarm member as the price of us continuing to support an old >> uncommon platform. Otherwise the apparent support is hollow. The BSDI >> port was viable for us to support as long as Bruce was using it daily, >> but with that gone, we need somebody else to be testing it. > Based on these emerging criteria, should we also remove the other > platforms on my original "marginal" list? > irix > osf > sco Possibly. What exactly is the difference between the "sco" and "unixware" ports, anyway? The one buildfarm member we have running SCO software (koi) chooses the unixware template. > irix and osf support was already dropped in Python 3.0, so probably > their time is up. Yeah, been a long time since I heard of either. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove dead ports?
On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On fre, 2012-05-04 at 18:25 -0400, Tom Lane wrote: > >> Furthermore, I would want to insist that a complainer provide a > >> buildfarm member as the price of us continuing to support an old > >> uncommon platform. Otherwise the apparent support is hollow. The BSDI > >> port was viable for us to support as long as Bruce was using it daily, > >> but with that gone, we need somebody else to be testing it. > > > Based on these emerging criteria, should we also remove the other > > platforms on my original "marginal" list? > > > irix > > osf > > sco > > Possibly. What exactly is the difference between the "sco" and > "unixware" ports, anyway? The one buildfarm member we have running > SCO software (koi) chooses the unixware template. Unixware was based on Unix System Labs System V, Release 4, while SCO was based on a 286 port of SVr2, or something like that. Both were produced by SCO, though Novell was also involved with it: http://en.wikipedia.org/wiki/UnixWare > > irix and osf support was already dropped in Python 3.0, so probably > > their time is up. > > Yeah, been a long time since I heard of either. Yep. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
Hannu Krosing writes:
> CAST is something that should convert one type to another, in this case
> a textual type to its "json value" representation and back.
> 'sometext'::text::json --> '"sometext"'
> and
> '"sometext"'::json::text --> 'sometext'
Well, that's a pretty interesting example, because if you expect that to
work like that, then what should happen with this?
'{"f1":4,"f2":2}'::text::json
'{"f1":4,"f2":2}'::json::text
Does the first of these produce a JSON object, or a quoted string?
At the moment you get the former, but it's pretty hard to argue that
it shouldn't produce a quoted string if transparent conversion is the
expectation. In the second case, do you end up with a JSON text (which
is what happens at the moment) or does it just slap some quotes around
the value as a string? I'm not convinced that you've made a principled
argument as to what should happen when.
In general, I think casts should only be used for conversions where
there is just one unsurprising choice of behavior, since the cast syntax
by definition doesn't provide any room for options. It's not clear to
me that JSON conversions are so obvious as to meet that standard. If
you start throwing random user-defined conversions into the mix, it's
even less obvious that there's only one unsurprising choice.
In the particular case of casts to and from text, we've essentially
set a project policy that those should behave equivalently to the type's
I/O conversion functions whenever possible. So I think the existing
behavior of those operations is correct and what you propose above is
wrong. There is certainly scope for a conversion function that takes
any random text string and produces a JSON quoted string from it, but
the cast operator is not the place for that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove dead ports?
Bruce Momjian writes: > On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote: >> Possibly. What exactly is the difference between the "sco" and >> "unixware" ports, anyway? The one buildfarm member we have running >> SCO software (koi) chooses the unixware template. > Unixware was based on Unix System Labs System V, Release 4, while SCO > was based on a 286 port of SVr2, or something like that. Oh, so the "sco" port actually refers to OpenServer? http://en.wikipedia.org/wiki/SCO_OpenServer That page makes it sound like it's more or less as current as Unixware, since both had their last updates in 2008/2009 timeframe (and both are presumably never going to see another one, with SCO the company being dead in all but name). The difference from our perspective is that we have a buildfarm member running Unixware, whereas it's anybody's guess whether the "sco" port still works or not. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove dead ports?
On 5 May 2012 09:59, Peter Eisentraut wrote: > Based on these emerging criteria, should we also remove the other > platforms on my original "marginal" list? > > irix Well, there hasn't been an IRIX release since 2006, and silicon graphics is defunct. The SGI brand lives on, though I think that that organisation isn't in any meaningful sense a successor - certainly, they don't produce the IRIX workstations (or any other) that were the main business of SGI for so long. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove dead ports?
On Sat, May 05, 2012 at 12:08:00PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote: > >> Possibly. What exactly is the difference between the "sco" and > >> "unixware" ports, anyway? The one buildfarm member we have running > >> SCO software (koi) chooses the unixware template. > > > Unixware was based on Unix System Labs System V, Release 4, while SCO > > was based on a 286 port of SVr2, or something like that. > > Oh, so the "sco" port actually refers to OpenServer? > > http://en.wikipedia.org/wiki/SCO_OpenServer > > That page makes it sound like it's more or less as current as Unixware, > since both had their last updates in 2008/2009 timeframe (and both > are presumably never going to see another one, with SCO the company > being dead in all but name). > > The difference from our perspective is that we have a buildfarm member > running Unixware, whereas it's anybody's guess whether the "sco" port > still works or not. Yes, sorry, I should have been clearer. SCO is both an OS and a company. The 'sco' references OpenServer. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] smart shutdown at end of transaction (was: Default mode for shutdown)
On Sat, Apr 28, 2012 at 4:00 AM, Robert Haas wrote: > On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane wrote: >> I'm not necessarily opposed to commandeering the name "smart" for the >> new behavior, so that what we have to find a name for is the old "smart" >> behavior. How about >> >> slow - allow existing sessions to finish (old "smart") >> smart - allow existing transactions to finish (new) >> fast - kill active queries >> immediate - unclean shutdown > > I could live with that. Really, I'd like to have fast just be the > default. But the above compromise would still be a big improvement > over what we have now, assuming the new smart becomes the default. Should this new shutdown mode wait for online backup like old "smart" does? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove dead ports?
On Sat, May 05, 2012 at 12:08:00PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Sat, May 05, 2012 at 11:26:32AM -0400, Tom Lane wrote: > >> Possibly. What exactly is the difference between the "sco" and > >> "unixware" ports, anyway? The one buildfarm member we have running > >> SCO software (koi) chooses the unixware template. > > > Unixware was based on Unix System Labs System V, Release 4, while SCO > > was based on a 286 port of SVr2, or something like that. > > Oh, so the "sco" port actually refers to OpenServer? > > http://en.wikipedia.org/wiki/SCO_OpenServer > > That page makes it sound like it's more or less as current as Unixware, > since both had their last updates in 2008/2009 timeframe (and both > are presumably never going to see another one, with SCO the company > being dead in all but name). > > The difference from our perspective is that we have a buildfarm member > running Unixware, whereas it's anybody's guess whether the "sco" port > still works or not. Well, absent user feedback, we could use our own 5-year rule and keep sco and unixware, and remove irix (2006). -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL/Python result set slicing broken in Python 3
On 04/05/12 20:00, Jan Urbański wrote:
On 03/05/12 11:04, Jan Urbański wrote:
On 02/05/12 20:18, Peter Eisentraut wrote:
This doesn't work anymore with Python 3:
rv = plpy.execute(...)
do_something(rv[0:1])
Sounds ugly. I'll take a look.
I found some instructions on how to deal with the Python 2/Python 3
slicing mess:
http://renesd.blogspot.com/2009/07/python3-c-api-simple-slicing-sqslice.html
Thanks to the helpful folk at #python I found out that the fix is much
easier. Attached is a patch that fixes the bug and passes regression
tests on Pythons 2.3 through 3.2.
Apparently once you implement PyMappingMethods.mp_subscript you can drop
PySequenceMethods.sq_slice, but I guess there's no harm in keeping it
(and I'm not sure it'd work on Python 2.3 with only mp_subscript
implemented).
Do we want to backpatch this? If so, I'd need to produce a version that
applies to the monolithic plpython.c file from the previous releases.
Cheers,
Jan
>From 000a1285d66c65c36ae6fa064266f00def5ee9d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan=20Urba=C5=84ski?=
Date: Sat, 5 May 2012 22:39:26 +0200
Subject: [PATCH] Fix slicing support for result objects for Python 3.
The old way of implementing slicing support by implementing
PySequenceMethods.sq_slice has been deprecated in Python 3, you should
not implement PyMappingMethods.mp_subscript. Do this by simply
proxying the call to the wrapped list of result dictionaries.
While at it, fix an incorrect comment about PLyResultObject->rows being
None if the result set is empty (it actually is an empty list in that
case).
---
src/pl/plpython/expected/plpython_spi.out | 55 +
src/pl/plpython/plpy_resultobject.c | 27 +-
src/pl/plpython/plpy_resultobject.h |2 +-
src/pl/plpython/sql/plpython_spi.sql | 36 +++
4 files changed, 118 insertions(+), 2 deletions(-)
diff --git a/src/pl/plpython/expected/plpython_spi.out b/src/pl/plpython/expected/plpython_spi.out
index 671c24e..54ef512 100644
--- a/src/pl/plpython/expected/plpython_spi.out
+++ b/src/pl/plpython/expected/plpython_spi.out
@@ -228,6 +228,61 @@ SELECT result_len_test($$UPDATE foo3 SET b= '' WHERE a = 2$$);
0
(1 row)
+CREATE FUNCTION result_subscript_test() RETURNS void
+AS $$
+result = plpy.execute("SELECT 1 AS c UNION SELECT 2 "
+ "UNION SELECT 3 UNION SELECT 4")
+
+plpy.info(result[1]['c'])
+plpy.info(result[-1]['c'])
+
+plpy.info([item['c'] for item in result[1:3]])
+plpy.info([item['c'] for item in result[::2]])
+
+result[-1] = {'c': 1000}
+result[:2] = [{'c': 10}, {'c': 100}]
+plpy.info([item['c'] for item in result[:]])
+
+# raises TypeError, but the message differs on Python 2.6, so silence it
+try:
+plpy.info(result['foo'])
+except TypeError:
+pass
+else:
+assert False, "TypeError not raised"
+
+$$ LANGUAGE plpythonu;
+SELECT result_subscript_test();
+INFO: 2
+CONTEXT: PL/Python function "result_subscript_test"
+INFO: 4
+CONTEXT: PL/Python function "result_subscript_test"
+INFO: [2, 3]
+CONTEXT: PL/Python function "result_subscript_test"
+INFO: [1, 3]
+CONTEXT: PL/Python function "result_subscript_test"
+INFO: [10, 100, 3, 1000]
+CONTEXT: PL/Python function "result_subscript_test"
+ result_subscript_test
+---
+
+(1 row)
+
+CREATE FUNCTION result_empty_test() RETURNS void
+AS $$
+result = plpy.execute("select 1 where false")
+
+plpy.info(result[:])
+
+$$ LANGUAGE plpythonu;
+SELECT result_empty_test();
+INFO: []
+CONTEXT: PL/Python function "result_empty_test"
+ result_empty_test
+---
+
+(1 row)
+
-- cursor objects
CREATE FUNCTION simple_cursor_test() RETURNS int AS $$
res = plpy.cursor("select fname, lname from users")
diff --git a/src/pl/plpython/plpy_resultobject.c b/src/pl/plpython/plpy_resultobject.c
index fcf8074..06ba2ee 100644
--- a/src/pl/plpython/plpy_resultobject.c
+++ b/src/pl/plpython/plpy_resultobject.c
@@ -23,6 +23,9 @@ static PyObject *PLy_result_item(PyObject *arg, Py_ssize_t idx);
static PyObject *PLy_result_slice(PyObject *arg, Py_ssize_t lidx, Py_ssize_t hidx);
static int PLy_result_ass_item(PyObject *arg, Py_ssize_t idx, PyObject *item);
static int PLy_result_ass_slice(PyObject *rg, Py_ssize_t lidx, Py_ssize_t hidx, PyObject *slice);
+static PyObject *PLy_result_subscript(PyObject *arg, PyObject *item);
+static PyObject *PLy_result_subscript(PyObject *arg, PyObject *item);
+static int PLy_result_ass_subscript(PyObject* self, PyObject* item, PyObject* value);
static char PLy_result_doc[] = {
"Results of a PostgreSQL query"
@@ -38,6 +41,12 @@ static PySequenceMethods PLy_result_as_sequence = {
PLy_result_ass_slice, /* sq_ass_slice */
};
+static PyMappingMethods PLy_result_as_mapping = {
+ PLy_result_length, /* mp_length */
+ PLy_result_subscript, /* mp_subscript */
+ PLy_result_ass_subscript, /* mp_ass_subscript */
+};
+
static PyMethodDef PLy_result_methods[] = {
{"colna
Re: [HACKERS] remove dead ports?
On Sat, May 5, 2012 at 12:44 PM, Bruce Momjian wrote: > Well, absent user feedback, we could use our own 5-year rule and keep > sco and unixware, and remove irix (2006). I think we should err on the side of removing less rather than more. It won't hurt anything much to leave these around for another few years. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] remove dead ports?
On 6 May 2012 01:06, Robert Haas wrote: > On Sat, May 5, 2012 at 12:44 PM, Bruce Momjian wrote: >> Well, absent user feedback, we could use our own 5-year rule and keep >> sco and unixware, and remove irix (2006). > > I think we should err on the side of removing less rather than more. > It won't hurt anything much to leave these around for another few > years. I think it's better to force users of platforms like IRIX and BSD/OS, platforms which are obsolete according to any practical definition, to use earlier branches that presumably are known to have had a certain amount of testing. Supporting these platforms while "flying blind" seems to rather devalue what it means for a platform to be supported by Postgres. Presumably these users don't plan to stay on their platform of choice forever, and don't have terribly demanding needs, so I don't really see that we're doing them any kind of disservice. Continuing to support these platforms is actually the less conservative option. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
