On Aug 11, 2010, at 11:35 AM, Andrew Dunstan wrote:
for i in select array_subscripts(myarray, 1) loop ...
That's not a built-in function AFAIK.
Pavel pointed out to me only yesterday that it is:
http://www.postgresql.org/docs/current/static/functions-srf.html#FUNCTIONS-SRF-SUBSCRIPTS
[moving discussion to -hackers]
Michael Meskes mich...@fam-meskes.de wrote:
Kevin Grittner kevin.gritt...@wicourts.gov schrieb:
Marcelo Mas m...@atg.com.uy wrote:
Valgrind reports memmory leak when getting decimal data.
I wonder how much overlap there is between this and the patch for
On 08/11/2010 02:39 PM, David E. Wheeler wrote:
On Aug 11, 2010, at 11:35 AM, Andrew Dunstan wrote:
for i in select array_subscripts(myarray, 1) loop ...
That's not a built-in function AFAIK.
Pavel pointed out to me only yesterday that it is:
On 08/11/2010 02:12 PM, Peter Eisentraut wrote:
Even if you don't, changing this would only mean that you
couldn't safely run make check concurrently in multiple branches.
That's exactly the point. The original discussion is here:
as tom pointed out - this is not possible.
there is no limit 20 in my case - i just used it to indicate that limiting does
not make the index scan possible which it does in some other cases.
the partial sort thing simon pointed out is what is needed at this point.
many thanks,
Andrew Dunstan and...@dunslane.net writes:
You original email said:
For some historic reasons, I have my local scripts set up so that
they build development instances using the hardcoded port 65432.
I think my response would be Don't do that.
Yeah ... or at least use a different port
On 11 August 2010 18:53, Robert Haas robertmh...@gmail.com wrote:
I think that there's a need for additional built-in array functions,
including one to succinctly test if an array has no elements.
What do you propose? I think the easiest ways to do it right now are:
array_length(arr, 1) is
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 9, 2010 at 10:41 AM, Robert Haas robertmh...@gmail.com wrote:
There's also the fact that it would probably end up parsing the data
twice. Given xmloption, I'm inclined to think Tom has it right:
provided xml_is_well_formed() that follows
On 08/11/2010 04:17 PM, Tom Lane wrote:
We should have the
buildfarm configuration such that any one run uses the same port number
for both installed and uninstalled regression tests. If Peter is dead
set on not changing pg_regress's default, then changing the makefiles to
enable use of the
Andrew Dunstan and...@dunslane.net writes:
Another way would be to have pg_regress honour an environment var like
PG_REGRESS_PORT, which the buildfarm script could use.
Yeah, that would work too. (Is it portable to Windows, though?)
I prefer the change-the-default approach mainly because it
On 08/11/2010 04:47 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
Another way would be to have pg_regress honour an environment var like
PG_REGRESS_PORT, which the buildfarm script could use.
Yeah, that would work too. (Is it portable to Windows, though?)
Should be
I
Peter Geoghegan peter.geoghega...@gmail.com writes:
What's wrong with something like array_is_empty(anyarray) returns
boolean?
What's that got to do with iterating over an array? We could certainly
provide it if it were commonly useful, but I'm not convinced of that.
On 21/07/10 23:40, Magnus Hagander wrote:
I've also set up the git server and the scripts around it, that we can
eventually use. This includes commit email sending, commit policy enforcement
(no merge commits, correct author/committer tag etc) and proper access control
(a modified version of the
Andrew Dunstan and...@dunslane.net writes:
On 08/11/2010 04:47 PM, Tom Lane wrote:
I prefer the change-the-default approach mainly because it wouldn't
require any documentation,
Yeah. The other advantage is that we would not need to wait until we had
got everyone to update their versions of
On Wed, Aug 11, 2010 at 5:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 08/11/2010 04:47 PM, Tom Lane wrote:
I prefer the change-the-default approach mainly because it wouldn't
require any documentation,
Yeah. The other advantage is that we would not
On 11/08/10 21:27, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Mon, Aug 9, 2010 at 10:41 AM, Robert Haasrobertmh...@gmail.com wrote:
There's also the fact that it would probably end up parsing the data
twice. Given xmloption, I'm inclined to think Tom has it right:
provided
On Wed, Aug 11, 2010 at 4:21 PM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
On 11 August 2010 18:53, Robert Haas robertmh...@gmail.com wrote:
I think that there's a need for additional built-in array functions,
including one to succinctly test if an array has no elements.
What do you
Robert Haas robertmh...@gmail.com writes:
... If you're still unhappy with it, you're going to need to
be more specific, or hack on it yourself.
I'm doing another pass over this. I notice that the documentation
claims the syntax of \e is \e [FILE] [LINE], but what is actually
implemented is
On Sat, Jul 24, 2010 at 06:57:18PM -0400, Joseph Adams wrote:
Update: I'm in the middle of cleaning up the JSON code (
http://git.postgresql.org/gitweb?p=json-datatype.git;a=summary if you
want to see the very latest ), so I haven't addressed all of the major
problems with it yet.
On Fri,
On Wed, 2010-08-11 at 15:27 -0700, David Fetter wrote:
I've been developing it as a contrib module because:
* I'd imagine it's easier than developing it as a built-in datatype
right away (e.g. editing a .sql.in file versus editing pg_type.h ).
* As a module, it has PGXS support, so
On Wed, Aug 11, 2010 at 03:40:36PM -0700, Joshua D. Drake wrote:
On Wed, 2010-08-11 at 15:27 -0700, David Fetter wrote:
I've been developing it as a contrib module because:
* I'd imagine it's easier than developing it as a built-in
datatype right away (e.g. editing a .sql.in file
On 08/11/2010 07:33 PM, David Fetter wrote:
I would be curious to the benefit of putting it in core. I have no
problem with the type but in core?
If it's not in core, the vast majority of users will not have it
installed, and nothing, in core or otherwise, will be able to count on
it.
On 11 August 2010 21:52, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan peter.geoghega...@gmail.com writes:
What's wrong with something like array_is_empty(anyarray) returns
boolean?
What's that got to do with iterating over an array?
Only that I'm of the opinion that we'd be well served
Andrew Dunstan wrote:
On 08/11/2010 07:33 PM, David Fetter wrote:
I would be curious to the benefit of putting it in core. I have no
problem with the type but in core?
If it's not in core, the vast majority of users will not have it
installed, and nothing, in core or otherwise, will
On Wed, Aug 11, 2010 at 07:39:37PM -0400, Andrew Dunstan wrote:
On 08/11/2010 07:33 PM, David Fetter wrote:
I would be curious to the benefit of putting it in core. I have no
problem with the type but in core?
If it's not in core, the vast majority of users will not have it
installed, and
On Wed, Aug 11, 2010 at 6:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
... If you're still unhappy with it, you're going to need to
be more specific, or hack on it yourself.
I'm doing another pass over this. I notice that the documentation
claims the
Robert Haas robertmh...@gmail.com writes:
I suggest that we punt the \sf portion of this patch back for rework for
the next CommitFest, and focus on getting the \e and \ef changes
committed. I think the \sf code can be a lot simpler if we get rid of
the code that's intended to recognize the
On Wed, Aug 11, 2010 at 11:35 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 11/08/10 16:46, Robert Haas wrote:
On Wed, Aug 11, 2010 at 1:17 AM, Fujii Masaomasao.fu...@gmail.com
wrote:
On Tue, Aug 10, 2010 at 9:30 AM, Robert Haasrobertmh...@gmail.com
wrote:
It
101 - 128 of 128 matches
Mail list logo
