On 01/20/2015 06:32 PM, David G Johnston wrote:
Andrew Dunstan wrote
On 01/20/2015 01:26 PM, Arne Scheffer wrote:
And a very minor aspect:
The term standard deviation in your code stands for
(corrected) sample standard deviation, I think,
because you devide by n-1 instead of n to keep
On 01/19/2015 12:28 AM, Tom Lane wrote:
An alternative would be to remove the pgsql directory at the end of the
run and thus do a complete fresh checkout each run. As you say it would
cost some time but save some space. At least it would be doable as an
option, not sure I'd want to make it
On 01/19/2015 09:53 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
But I'm wondering if we should look at using the tricks git-new-workdir
uses, setting up symlinks instead of a full clone. Then we'd have one
clone with a bunch of different work dirs. That plus
On 01/18/2015 09:20 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/18/2015 05:48 PM, Tom Lane wrote:
One of the biggest causes of buildfarm run failures is out of disk
space. That's not just because people are running buildfarm critters
on small slow machines; it's
On 01/18/2015 05:48 PM, Tom Lane wrote:
One of the biggest causes of buildfarm run failures is out of disk
space. That's not just because people are running buildfarm critters
on small slow machines; it's because make check-world is an enormous
space hog. Some numbers from current HEAD:
On 01/16/2015 12:22 PM, Pavel Stehule wrote:
There two possible transformations:
row_to_array -- [[key1, value1],[key2, value2], ...]
row_to_row_array -- [(key1, value1), (key2, value2), ... ]
If we're going to go that route, I think it makes more sense to
On 01/14/2015 07:29 PM, Tom Lane wrote:
dst1 doesn't get an OID column:
regression=# create table src1 (f1 int) with oids;
CREATE TABLE
regression=# create table dst1 (like src1);
CREATE TABLE
regression=# \d+ src1
Table public.src1
Column | Type | Modifiers |
On 01/09/2015 02:15 PM, David Fetter wrote:
Some C cleanups...
Not quite enough cleanup. As I told you on IRC, the only addition to
common.h should be the declaration of recognized_connection_string.
These do not belong there (they belong in common.c):
+static const char
On 01/10/2015 09:32 AM, Andres Freund wrote:
On 2015-01-10 09:16:07 -0500, Andrew Dunstan wrote:
+static const char uri_designator[] = postgresql://;
+static const char short_uri_designator[] = postgres://;
These declarations in common.h would cause a separate instance of these
pieces
On 01/08/2015 08:42 PM, Aaron Botsis wrote:
On Jan 8, 2015, at 3:44 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/08/2015 03:05 PM, Aaron Botsis wrote:
It's also unnecessary. CSV format, while not designed for this, is nevertheless
sufficiently flexible to allow successful import
On 01/08/2015 03:05 PM, Aaron Botsis wrote:
It's also unnecessary. CSV format, while not designed for this, is
nevertheless sufficiently flexible to allow successful import of json
data meeting certain criteria (essentially no newlines), like this:
copy the_table(jsonfield)
from
On 01/07/2015 08:25 AM, Aaron Botsis wrote:
Hi folks, I was having a problem importing json data with COPY. Lots
of things export data nicely as one json blob per line. This is
excellent for directly importing into a JSON/JSONB column for analysis.
...Except when there’s an embedded
On 01/07/2015 03:22 AM, Heikki Linnakangas wrote:
On 01/07/2015 01:54 AM, Andrew Dunstan wrote:
I also think it's a great idea. But I think we should consider the name
carefully. pg_resync might be a better name. Strictly, you might not be
quite rewinding, AIUI.
pg_resync sounds too generic
On 12/21/2014 02:50 PM, Andrew Dunstan wrote:
On 12/21/2014 02:12 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 12/21/2014 01:23 PM, Alvaro Herrera wrote:
The point, I think, is that without atomic instructions you have to
hold
a lock while incrementing the counters
On 01/06/2015 03:39 PM, Peter Eisentraut wrote:
I applaud the ingenuity on all levels in this patch. But it seems to me
that there is way too much backend knowledge encoded and/or duplicated
in a front-end program.
If this ends up shipping, it's going to be a massively popular tool. I
see it
I don't wish to seem humorless, but I think this should probably be changed:
root/HEAD/pgsql/src/test/regress/sql/event_trigger.sql:248: RAISE
EXCEPTION 'I''m sorry Sir, No Rewrite Allowed.';
Quite apart from any other reason, the Sir does seem a bit sexist - we
have no idea of the gender
On 12/15/2014 12:04 PM, Andres Freund wrote:
I think the safest fix would be to defer catchup interrupt processing
while you're in this mode. You don't really want to be processing any
remote sinval messages at all, I'd think.
Well, we need to do relmap, smgr and similar things. So I think
On 01/03/2015 04:41 PM, Magnus Hagander wrote:
We could do worse than to say it's in the directory printed by
pg_config --sysconfdir.
Yeah. But let's make sure we include usually /etc or something like
that.
But it's not usually /etc. Certainly it's not in the PGDG RPM builds
On 12/31/2014 07:49 AM, Tomas Vondra wrote:
On 28.12.2014 00:46, Noah Misch wrote:
On Tue, Dec 23, 2014 at 03:32:59PM +0100, Tomas Vondra wrote:
On 23.12.2014 15:21, Andrew Dunstan wrote:
No, config_opts is what's passed to configure. Try something like:
if ($branch eq 'REL9_0_STABLE
On 12/31/2014 12:26 PM, Tomas Vondra wrote:
On 31.12.2014 17:29, Andrew Dunstan wrote:
Sorry, I should have tested it. This seems to work:
if ($branch eq 'REL9_0_STABLE')
{
$PGBuild::Options::skip_steps .= ' pl-install-check';
$main::skip_steps{'pl-install-check
On 12/30/2014 09:20 AM, Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 29. Dezember 2014 12:55:11 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Given the lack of previous complaints, this probably isn't backpatching
material, but it sure seems like a bit of attention to consistency
On 12/28/2014 04:58 PM, Noah Misch wrote:
On Sat, Oct 11, 2014 at 09:07:46AM -0400, Peter Eisentraut wrote:
On 10/11/14 1:41 AM, Noah Misch wrote:
Good question. It would be nice to make the change there, for the benefit of
other consumers. The patch's setlocale_native_forked() assumes it
On 12/23/2014 07:14 AM, Tomas Vondra wrote:
On 23.12.2014 09:19, Noah Misch wrote:
On Sat, Dec 20, 2014 at 07:28:33PM +0100, Tomas Vondra wrote:
On 20.12.2014 19:05, Tom Lane wrote:
Locale cs_CZ.WIN-1250 is evidently marked with a codeset property of
ANSI_X3.4-1968 (which means old-school
On 12/23/2014 04:36 AM, Ravi Kiran wrote:
hi all,
Is postgres source code compatible with mysql database?? If it is,
could someone could give me some links so that I can do that.
I want to hack into the postgres source code, but as I am comfortable
with mysql, I want to use the mysql
On 12/22/2014 10:41 PM, Peter Eisentraut wrote:
On 12/22/14 7:56 PM, Andrew Dunstan wrote:
Currently the buildfarm animal crake (my development instance) is
running the bin check, but not any other animal. These tests still take
for too long, not least because each set of tests requires
On 12/23/2014 11:11 AM, Andrew Dunstan wrote:
On 12/22/2014 10:41 PM, Peter Eisentraut wrote:
On 12/22/14 7:56 PM, Andrew Dunstan wrote:
Currently the buildfarm animal crake (my development instance) is
running the bin check, but not any other animal. These tests still take
for too long
On 12/21/2014 02:18 PM, Tom Lane wrote:
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes:
I work with some customer that have databases with a lot of schemas and
sometimes we need to run manual VACUUM in one schema, and would be nice to
have a new option to run vacuum in
Currently the buildfarm animal crake (my development instance) is
running the bin check, but not any other animal. These tests still take
for too long, not least because each set of tests requires a separate
install.
I have complained about this before, but we don't seem to have made any
On 04/07/2014 04:19 PM, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I just noticed that this patch not only adds min,max,stddev, but it also
adds the ability to reset an entry's counters. This hasn't been
mentioned in this thread at all; there has been no discussion on
On 12/21/2014 01:23 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
On my blog Peter Geoghegan mentioned something about atomic fetch-and-add
being useful here, but I'm not quite sure what that's referring to. Perhaps
someone can give me a pointer.
The point, I think, is that without atomic
On 11/15/2014 05:56 PM, Andrew Dunstan wrote:
On 11/13/2014 11:41 AM, Andrew Dunstan wrote:
On 11/13/2014 11:09 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I often get annoyed because psql is a bit too aggressive when it
decides
whether to put output through the pager
On 12/21/2014 02:12 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 12/21/2014 01:23 PM, Alvaro Herrera wrote:
The point, I think, is that without atomic instructions you have to hold
a lock while incrementing the counters.
Hmm, do we do that now?
We already have
On 12/20/2014 12:32 PM, Tom Lane wrote:
Immediate recommendation is to restart the buildfarm critters with the
missing locale removed from their configurations. If you can find the
locale again somewhere, by all means re-enable it, but better less testing
than no testing in the meantime.
On 12/18/2014 03:02 AM, Michael Paquier wrote:
On Fri, Dec 12, 2014 at 10:45 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Another thing in that patch was that I had to add the sql/ directory to
the source tree, but other than that .gitignore file it was empty.
Maybe pg_regress should
On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:
On 12/17/2014 10:03 AM, Albe Laurenz wrote:
David Fetter wrote:
I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.
This came up in the context of connecting to a cloud hosting
On 12/17/2014 10:23 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 12/16/2014 04:44 PM, Tom Lane wrote:
I've put this in dromedary as well (though the HEAD build that's running
right this moment is still using the 4.13 script). I take it I don't need
to adjust
On 12/17/2014 11:34 AM, Andrew Dunstan wrote:
On 12/17/2014 10:23 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 12/16/2014 04:44 PM, Tom Lane wrote:
I've put this in dromedary as well (though the HEAD build that's
running
right this moment is still using the 4.13 script
On 12/16/2014 09:31 AM, Alvaro Herrera wrote:
Hi Andrew,
Did you have a chance to review this?
Oh, darn, not yet. I will try to take a look today.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 12/16/2014 04:34 AM, Amit Kapila wrote:
On Tue, Dec 16, 2014 at 12:58 PM, Amit Kapila amit.kapil...@gmail.com
mailto:amit.kapil...@gmail.com wrote:
On Sun, Dec 14, 2014 at 11:54 AM, Amit Kapila
amit.kapil...@gmail.com mailto:amit.kapil...@gmail.com wrote:
On Sat, Dec 13, 2014 at 10:48
On 12/16/2014 01:38 PM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Including all of the other names of people who made important
contributions, many of which consisted of reviewing, would make that
release note item - and many others - really, really long, so I'm not
in
On 12/16/2014 11:22 AM, Andrew Dunstan wrote:
On 12/16/2014 09:31 AM, Alvaro Herrera wrote:
Hi Andrew,
Did you have a chance to review this?
Oh, darn, not yet. I will try to take a look today.
I have pushed this change, and crake will be running the code. See
https://github.com
On 12/16/2014 04:02 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
I have pushed this change, and crake will be running the code. See
https://github.com/PGBuildFarm/client-code/commit/d656c1c3ce46f290791c5ba5ede2f8ac8dfa342e
Crake just uploaded its first test results with the testmodules
On 12/16/2014 04:44 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I have pushed this change, and crake will be running the code. See
https://github.com/PGBuildFarm/client-code/commit/d656c1c3ce46f290791c5ba5ede2f8ac8dfa342e
Any brave buildfarm owners on *nix can try
On 12/14/2014 12:05 PM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
On 12/14/2014 10:35 PM, Mark Cave-Ayland wrote:
Compare this to say, for example, huge patches such as RLS.
I specifically objected to that being flattened into a single monster
patch when I saw that'd been
On 12/13/2014 10:00 AM, Michael Paquier wrote:
Hi all,
Looking at the CF app as of today, there is the following status for
pending patches:
- Needs Review: 18
- Waiting on Author: 1
- Ready for Committer: 8
And the next coming fest that should begin on Monday has this status:
- Needs Review:
On 11/08/2014 12:37 AM, Michael Paquier wrote:
On Sat, Nov 8, 2014 at 5:55 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Michael Paquier wrote:
On Fri, Nov 7, 2014 at 2:31 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
I thought the consensus was that the SQL-callable function
On 11/20/2014 02:27 AM, Amit Kapila wrote:
On Wed, Nov 19, 2014 at 11:46 PM, Robert Haas robertmh...@gmail.com
mailto:robertmh...@gmail.com wrote:
On Tue, Nov 18, 2014 at 9:19 AM, Alvaro Herrera
alvhe...@2ndquadrant.com mailto:alvhe...@2ndquadrant.com wrote:
Right, but they provide same
On 11/24/2014 07:26 AM, Heikki Linnakangas wrote:
On 09/25/2014 05:10 AM, Robert Haas wrote:
On Wed, Sep 24, 2014 at 2:34 PM, Fabien COELHO coe...@cri.ensmp.fr
wrote:
Sigh.
How to transform a trivial 10 lines patch into a probably 500+ lines
project
involving flex bison some non trivial
On 12/13/2014 01:19 PM, Fabien COELHO wrote:
As it doesn't have documentation, I'm inclined to say we should mark
this as Waiting on Author or Returned with Feedback.
I'm planing to have a detailed look at Robert's patch before the end
of the year. I could update pgbench documentation
On 11/03/2014 07:35 AM, Fabrízio de Royes Mello wrote:
On Mon, Nov 3, 2014 at 3:12 AM, Rushabh Lathia
rushabh.lat...@gmail.com mailto:rushabh.lat...@gmail.com wrote:
Patch looks good, assigning to committer.
Thanks for your review!
Committed.
cheers
andrew
--
Sent via pgsql-hackers
On 12/08/2014 01:00 PM, Andrew Dunstan wrote:
On 12/08/2014 04:21 AM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
OK, here is a new patch version that
* uses find_coercion_path() to find the cast function if any, as
discussed elsewhere
* removes calls to getTypeOutputInfo() except
On 12/12/2014 01:10 PM, Andrew Dunstan wrote:
On 12/08/2014 01:00 PM, Andrew Dunstan wrote:
On 12/08/2014 04:21 AM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
OK, here is a new patch version that
* uses find_coercion_path() to find the cast function if any, as
discussed elsewhere
On 12/12/2014 01:55 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Also here is a patch factored out which applies the
find_coercion_pathway change to json.c. I'm inclined to say we should
backpatch this to 9.4 (and with a small change 9.3). Thoughts?
Meh. Maybe I'm just
On 12/09/2014 06:19 PM, Josh Berkus wrote:
On 12/09/2014 09:41 AM, Alvaro Herrera wrote:
The first thing where this matters is tuple descriptor expansion in
parse analysis; at this stage, things such as * (in select *) are
turned into a target list, which must be sorted according to attlognum.
On 12/08/2014 04:21 AM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
OK, here is a new patch version that
* uses find_coercion_path() to find the cast function if any, as
discussed elsewhere
* removes calls to getTypeOutputInfo() except where required
* honors a cast to json only
On 12/04/2014 02:44 PM, Peter Eisentraut wrote:
On 12/4/14 11:38 AM, Peter Eisentraut wrote:
On 11/19/14 11:11 PM, Peter Eisentraut wrote:
I noticed this item was still in the 9.4 code. Looking at the original
submission
On 12/04/2014 03:47 PM, Andrew Dunstan wrote:
On 12/04/2014 02:44 PM, Peter Eisentraut wrote:
On 12/4/14 11:38 AM, Peter Eisentraut wrote:
On 11/19/14 11:11 PM, Peter Eisentraut wrote:
I noticed this item was still in the 9.4 code. Looking at the
original
submission
(http
On 12/04/2014 03:53 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
However, there is more work to do. As Tom noted upthread, psql's calculation
of the number of lines is pretty bad. For example, if I do:
\pset pager_min_lines 100
select * from generate_series(1,50);
the pager still
On 12/01/2014 05:39 PM, Tomas Vondra wrote:
Hi all,
while working on the patch decreasing amount of memory consumed by
array_agg [1], I've ran into some strange OOM issues. Reproducing them
using the attached SQL script is rather simple.
[1]
On 11/26/2014 11:48 AM, Andrew Dunstan wrote:
On 11/26/2014 11:19 AM, Tom Lane wrote:
bo...@edookit.com writes:
The hstore_to_json_loose(hstore) produces an invalid JSON in the
following
case:
SELECT hstore_to_json_loose(hstore(ARRAY ['name'], ARRAY ['1.'] :: TEXT
[]))
Output: {name: 1
On 11/30/2014 11:45 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
what do you want to do about this? In the back branches, exposing a
function like this would be an API change, wouldn't it? Perhaps there we
just need to pick up the 100 lines or so involved from json.c and copy
On 11/30/2014 04:31 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
OK, here's the patch.
Can we make IsValidJsonNumber() take a const char *? Also its
comment should specify that it doesn't require nul-terminated
input, if indeed it doesn't. Otherwise +1
On 11/27/2014 04:12 AM, Ian Barwick wrote:
Hi
pg_regress provides the command line option --dbname,
which is described in the help output thusly:
--dbname=DBuse database DB (default regression)
It does however accept multiple comma separated names
and will create a database for each
On 11/25/2014 11:46 PM, Michael Paquier wrote:
Hi all,
In the stuff I work on in a daily basis there are a couple of
extensions written in C++, compiling them with MSVC on Windows using
slightly-different scripts available in src/tools after copying them
directly in contrib/. However, the
On 11/26/2014 11:19 AM, Tom Lane wrote:
bo...@edookit.com writes:
The hstore_to_json_loose(hstore) produces an invalid JSON in the following
case:
SELECT hstore_to_json_loose(hstore(ARRAY ['name'], ARRAY ['1.'] :: TEXT
[]))
Output: {name: 1.}
The actual output is indeed incorrect as JSON does
On 11/26/2014 11:48 AM, Andrew Dunstan wrote:
In json.c we now check numbers like this:
JsonLexContext dummy_lex;
boolnumeric_error;
...
dummy_lex.input = *outputstr == '-' ? outputstr + 1 : outputstr;
dummy_lex.input_length = strlen(dummy_lex.input
On 11/26/2014 03:48 PM, Tom Lane wrote:
Arguably,
populate_record_worker should be smart enough to convert somehow, but
it isn't today. Looks to me like it wouldn't succeed for the comparable
case of converting a sub-object to a Postgres composite type, either.
I'm satisfied with regarding
On 11/26/2014 05:26 PM, Peter Geoghegan wrote:
On Wed, Nov 26, 2014 at 2:00 PM, Andrew Dunstan and...@dunslane.net wrote:
The client's question is whether this is not a bug. It certainly seems like
it should be possible to plan a query without chewing up this much memory,
or at least
On 11/26/2014 05:00 PM, Andrew Dunstan wrote:
Attached is some anonymized DDL for a fairly complex schema from a
PostgreSQL Experts client. Also attached is an explain query that runs
against the schema. The client's problem is that in trying to run the
explain, Postgres simply runs out
On 11/22/2014 06:20 AM, Pavel Stehule wrote:
Hi
I did a week training and here are some ideas from people, who are
starting with Postgres.
1. possibility to set server side variables simply as psql option.
Motivation - more simple and natural changing datestyle for psql in
shell scripts.
I noticed the other day that psql doesn't honor ECHO_HIDDEN for \sf.
This looks on a somewhat cursory examination to be the only significant
place that doesn't. Is there any reason for this, or should I just
adjust it so that it uses PSQLexec like pretty much every other slash
command?
On 11/21/2014 11:11 AM, Pavel Stehule wrote:
2014-11-21 16:46 GMT+01:00 Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net mailto:and...@dunslane.net
writes:
I noticed the other day that psql doesn't honor ECHO_HIDDEN for \sf
On 11/21/2014 12:32 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/21/2014 11:11 AM, Pavel Stehule wrote:
I noticed the other day that psql doesn't honor ECHO_HIDDEN for \sf.
OK. it was so trivial I just did it.
I think it may not be quite as trivial
On 11/21/2014 01:05 PM, Andrew Dunstan wrote:
On 11/21/2014 12:32 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/21/2014 11:11 AM, Pavel Stehule wrote:
I noticed the other day that psql doesn't honor ECHO_HIDDEN for \sf.
OK. it was so trivial I just did it.
I think
On 11/21/2014 02:44 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Well, now we get things like this:
ERROR: more than one function named abc
LINE 1: SELECT 'abc'::pg_catalog.regproc::pg_catalog.oid
whereas minimal_error_message suppressed the second line. If we want
On 11/21/2014 02:44 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Well, now we get things like this:
ERROR: more than one function named abc
LINE 1: SELECT 'abc'::pg_catalog.regproc::pg_catalog.oid
whereas minimal_error_message suppressed the second line. If we want
On 11/20/2014 02:28 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 20, 2014 at 1:56 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
I don't think that there is a universally compelling right or wrong to
questions like this, it is more a matter of taste. Is it more
On 11/19/2014 06:35 AM, Simon Riggs wrote:
On 18 November 2014 21:19, Petr Jelinek p...@2ndquadrant.com wrote:
Personally, I see this as natural extension of the conditional block control
which we already have for loops with CONTINUE WHEN and EXIT WHEN. This
basically extends it to any block
On 11/18/2014 04:23 AM, Simon Riggs wrote:
On 18 November 2014 01:00, Jim Nasby jim.na...@bluetreble.com wrote:
On 11/17/14, 4:58 PM, Simon Riggs wrote:
Great, looks good to me, marking as ready for committer.
What is wrong with using IF ?
It's a hell of a lot wordier. I've previously
On 11/18/2014 02:53 PM, Jim Nasby wrote:
On 11/18/14, 9:31 AM, Andrew Dunstan wrote:
Frankly, I find this whole proposal, and all the suggested
alternatives, somewhat ill-conceived. PLPGSQL is a wordy language. If
you want something more terse, use something else. Adding these sorts
On 11/18/2014 04:11 PM, Pavel Stehule wrote:
2014-11-18 21:27 GMT+01:00 Andrew Dunstan and...@dunslane.net
mailto:and...@dunslane.net:
On 11/18/2014 02:53 PM, Jim Nasby wrote:
On 11/18/14, 9:31 AM, Andrew Dunstan wrote:
Frankly, I find this whole proposal
On 11/18/2014 04:58 PM, Adam Brightwell wrote:
All,
Currently, I am using int32 simply because int64 is causing some
issues. The issue is that genbki.pl http://genbki.pl is not
able to associate it with the int8 type as defined in pg_type.h.
Therefore Schema_pg_authid in
This tiny change fixes what I think is a longstanding bug in psql. I
causes the first line of every cell to be counted twice, whereas it
should in fact be excluded from extra_lines / extra_row_output_lines.
The bug appears to date back to commit 43ee2282 in 2008. Changing it
appears to make
On 11/13/2014 11:41 AM, Andrew Dunstan wrote:
On 11/13/2014 11:09 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I often get annoyed because psql is a bit too aggressive when it
decides
whether to put output through the pager, and the only way to avoid this
is to turn
I often get annoyed because psql is a bit too aggressive when it decides
whether to put output through the pager, and the only way to avoid this
is to turn the pager off (in which case your next query might dump many
thousands of lines to the screen). I'd like a way to be able to specify
a
On 11/13/2014 11:09 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I often get annoyed because psql is a bit too aggressive when it decides
whether to put output through the pager, and the only way to avoid this
is to turn the pager off (in which case your next query might dump
On 11/10/2014 10:19 AM, Robert Haas wrote:
On Mon, Nov 10, 2014 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Attached are patches meant for HEAD and 9.2-9.4 respectively.
BTW, has anyone got an opinion about whether to stick the full fix into
9.4? The argument for, of course, is
On 11/08/2014 09:26 AM, Robert Haas wrote:
On Fri, Nov 7, 2014 at 11:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Thoughts?
I'm not sure whether this is safe enough to back-patch, but it seems
like we should probably plan to back-patch *something*, because the
status quo isn't great either.
On 11/08/2014 11:24 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/08/2014 09:26 AM, Robert Haas wrote:
I'm not sure whether this is safe enough to back-patch, but it seems
like we should probably plan to back-patch *something*, because the
status quo isn't great either
On 11/08/2014 12:14 PM, Tom Lane wrote:
I assume that's what you would propose for just the stable branches, and
that going forward we'd always use the aliases from the RTE?
That would be my druthers. But given the lack of complaints, maybe we
should just stick to the
On 11/08/2014 12:40 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/08/2014 12:14 PM, Tom Lane wrote:
That would be my druthers. But given the lack of complaints, maybe we
should just stick to the more-backwards-compatible behavior until someone
does complain. Thoughts
On 11/08/2014 04:19 PM, Ross Reedstrom wrote:
I've no opinion on the not respecting aliases aspect of this, but both
the hstore and json emtpy keys case breaks the format: it's duplicate keys
that collapse to a single value, and expected keynames are missing.
The insidious bit about this bug
On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
This is a serious bug in 9.3.5 and 9.4 beta3:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Example:
testjson=# select count(*) from document_acl;
count
---
426
(1 row)
testjson=#
On 10/28/2014 09:49 AM, Andrew Dunstan wrote:
On 10/27/2014 05:57 PM, Alvaro Herrera wrote:
Anyway this whole business of searching through the CASTSOURCETARGET
syscache seems like it could be refactored. If I'm counting correctly,
that block now appears four times (three in this patch
On 11/07/2014 11:17 AM, Andrew Dunstan wrote:
On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
This is a serious bug in 9.3.5 and 9.4 beta3:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Example:
testjson=# select count(*) from document_acl
On 11/07/2014 04:59 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Could this be a bug in lookup_rowtype_tupdesc()?
I think
In 9.3 we changed the way json generating functions worked by taking
account of cast functions to json from non-builtin types, such as hstore.
In 9.5 I am proposing to provide similar functionality for jsonb. The
patch actually takes account of cast functions to both jsonb and json
(with
On 11/06/2014 03:58 PM, Tom Lane wrote:
Andrew Dunstan andrew.duns...@pgexperts.com writes:
In 9.3 we changed the way json generating functions worked by taking
account of cast functions to json from non-builtin types, such as hstore.
In 9.5 I am proposing to provide similar functionality
On 11/04/2014 01:45 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
here's a patch for a utility function to look up the cast function for
a from/to pair of types, as recently suggested by Alvaro. Although it
only contains one use (in json.c), the upcoming jsonb generators would
On 11/05/2014 10:10 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/04/2014 01:45 PM, Tom Lane wrote:
In short, I'd rather see this addressed through functions with slightly
higher-level APIs that are capable of covering more cases. In most cases
it'd be best if callers
801 - 900 of 8267 matches
Mail list logo
