Re: [HACKERS] JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
On Fri, 2012-05-04 at 15:59 -0400, Robert Haas wrote:
On Fri, May 4, 2012 at 3:49 PM, Hannu Krosing ha...@krosing.net wrote:
On Fri, 2012-05-04 at 09:52 -0400, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com writes:
On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
So given that do we do anything about this now, or wait till 9.3?
I'd like the json support in 9.2 updated as follows
I think it's too late to be entertaining proposals for such changes in
9.2. If we had concluded that the existing functions were actively
wrong or a bad idea,
I think that hard-coding postgresql text representation as our json
representation without a possibility for the user tio easily fix it
without rewriting foll xx_to_json() functions is borderline actively
wrong.
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.
PostgreSQL CAST is different from casting a C pointer, they actually
perform a conversion when defined WITH FUNCTION or WITH INOUT.
And they pass value unchanged when defined WITHOUT FUNCTION.
Casts _do_not_ perform syntax checks, they assume the source to be of
the type castted from and they return result of the target type.
I think you are confusing input/output formatting with CAST here.
This confusion about cast-as-syntax-check probably qualifies as
something being actively wrong with current implementation, though it
does not seem to be something actively defined (there are no casts
defined for json type) but rather an artifact of how postgresql input
works.
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'
the suggested syntax check only should only be done by the type i/o
functions json_in(cstring) and json_recv(internal) and not casts.
Casts should do casting, that in PostgreSQL means type conversion
We can have constructors for
JSON, but they've got to be separate from the casting machinery.
Currently we do have constructors - json_in(csting) and
json_recv(internal)
These are the ones that should and do check for correct syntax.
Some more confusiong examples for pondering on cast vs i/o functions
Some of the difficulties of understanding and explaining what a json
type should be are exemplified in the following
hannu=# create table jtest(plaintext text, jsontext json);
CREATE TABLE
hannu=# insert into jtest values('A','A');
hannu=# insert into jtest values('true','true');
hannu=# insert into jtest values('null','null');
hannu=# insert into jtest values(null,null);
hannu=# select row_to_json(jtest) from jtest;
row_to_json
--
{plaintext:\A\,jsontext:A}
{plaintext:true,jsontext:true}
{plaintext:null,jsontext:null}
{plaintext:null,jsontext:null}
(4 rows)
hannu=# insert into jtest values('a','a');
ERROR: invalid input syntax for type json
LINE 1: insert into jtest values('a','a');
^
DETAIL: line 1: Token a is invalid.
--
---
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] JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?
On Fri, 2012-05-04 at 16:12 -0400, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Fri, May 4, 2012 at 3:49 PM, Hannu Krosing ha...@krosing.net 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. It is possible that that can be made to work, but it's a research project, not something to be crammed into 9.2 at the last possible minute. In any case, I really dislike the idea that array_to_json and row_to_json would contain two entirely different behaviors. Leave the extensibility ideas for a future to_json() function. I did not mean that array_to_json and row_to_json would be different than the generic to_json, just that they would be thin wrappers around the to_json function which check that the arguments are of the correct types for casting to JSON text. They need to recurse to each other and generic to_json anyway. regards, tom lane -- --- 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] 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 br...@momjian.ushttp://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 br...@momjian.ushttp://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 pete...@gmx.net 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 pete...@gmx.net 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 br...@momjian.ushttp://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 ha...@2ndquadrant.com 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 br...@momjian.us 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 pete...@gmx.net 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 br...@momjian.us 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 br...@momjian.ushttp://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 robertmh...@gmail.com wrote: On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us 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 br...@momjian.us 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 br...@momjian.ushttp://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?= wulc...@wulczer.org
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[] = {
{colnames,
Re: [HACKERS] remove dead ports?
On Sat, May 5, 2012 at 12:44 PM, Bruce Momjian br...@momjian.us 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 robertmh...@gmail.com wrote: On Sat, May 5, 2012 at 12:44 PM, Bruce Momjian br...@momjian.us 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
