Hello all,
I am providing a patch to allow you to change the output of a boolean
value in psql much like you can do with NULL. A client requested this
feature and we thought it may appeal to someone else in the community.
The patch includes updated docs and a regression test. The code
changes
Six years ago, we punted on allowing rules to use OLD and NEW in
multi-row VALUES constructs, because we didn't have LATERAL:
http://archives.postgresql.org/pgsql-hackers/2006-08/msg00044.php
I thought maybe that restriction could be fixed now that we do have
LATERAL, and indeed the attached
On Sat, 2012-08-18 at 18:10 +0400, Alexander Korotkov wrote:
On Thu, Aug 16, 2012 at 3:46 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I committed the patch now, but left out the support for
adjacent for now. Not because there was necessarily anything
After upgrading from 8.4 to 9.1, one of my plperl functions stopped working
properly.
For some reason, when matching a string using a regex, the $1 variable
cannot be returned directly using return_next() but must be
set to a variable first.
If returned directly, it appears to be cached in some
Interactively dropping primary key constraints has been annoying me.
I believe this patch fixes that, hopefully for other kinds of
cataloged constraints as well.
I believe this finishes, at least for a while, my tab-completion related gripes.
Cheers,
Jeff
drop_constraint_complete_v1.patch
On Sat, 2012-07-28 at 17:50 -0400, Tom Lane wrote:
which would come
back to bite us if we ever try to support index-only scans with SPGiST.
I'm confused:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=92203624934095163f8b57b5b3d7bbd2645da2c8
And the patch that was just
On Fri, Aug 17, 2012 at 7:18 PM, Jeff Janes jeff.ja...@gmail.com wrote:
tab completion will add USING after CLUSTER VERBOSE, as if VERBOSE
were the name of a table.
Instead of just making it not do the wrong thing, I tried to make it
actually do the right thing.
It doesn't fill in the
On Thu, Aug 16, 2012 at 4:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 15.08.2012 11:34, Alexander Korotkov wrote:
Ok, we've to decide if we need standard histogram. In some cases it can
be used for more accurate estimation of and operators.
But I think it is
On Mon, 2012-06-25 at 17:46 +0900, Vlad Arkhipov wrote:
It's not sufficient to store only a period of validity for a row. If two
transactions started in the same time change the same record, you have a
problem with TSTZRANGE type because it's normalized to empty interval.
That's an
On Mon, 2012-06-18 at 15:12 +0400, Alexander Korotkov wrote:
Hackers,
While experimenting with gistchoose I achieve interesting results
about relation of gistchoose behaviour and gist index bloat.
...
Current implementation of gistchoose select first index tuple which
have minimal
If there is some syntax that offers a convenient shorthand for WHERE,
that's fine with me. Or using two tables, one called foo and one called
foo_history, is also fine. But I don't want the DML syntax to introduce
new mechanisms that aren't available without the fancy syntax (though
new DDL
On 08/19/2012 03:01 AM, Jeff Janes wrote:
Or would you instead say that
changes made to a sequence are immediately visible to all other
transactions ?
Yes, that sounds better.
OK, how about the attached series, then?
The 2nd probably needs improvement - and I expect I've missed some other
12 matches
Mail list logo
