On Fri, Nov 4, 2011 at 16:04, Tom Lane wrote:
> Magnus Hagander writes:
>> Updated patch attached that does this, and the proper schema qualifications.
>
> I'd schema-qualify the quote_ident and regclass names too.
>
> Also, just as a matter of style, I think it'd be better to assign short
> alia
On Fri, Nov 4, 2011 at 16:13, Tom Lane wrote:
> Magnus Hagander writes:
>> Would you find it better if we showed blank (NULL) when it was -1?
>
> Yeah, I would. Seems less confusing.
Adjusted per this, renamed to "Stats target", and applied.
--
Magnus Hagander
Me: http://www.hagander.net/
On Tue, Oct 11, 2011 at 10:40:26AM +0200, Pavel Stehule wrote:
> What do you think about this idea?
+1, belatedly. Having inherent casts to/from text since version 8.3 has
smoothed out some aggravating corner cases. If the patch isn't invasive and the
casts are all explicit-only, I anticipate a
During the closing days of the 9.1 release, we had discussed that we
should add privileges on types (and domains), so that owners can prevent
others from using their types because that would prevent the owners from
changing them in certain ways. (Collations have similar issues and work
quite simil
We only build the language plpython2u or plpython3u, not both, in any
build, but we always install the extension control files for all
variants. Is there a reason for this, or just an oversight?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On fre, 2011-11-04 at 07:34 -0400, Noah Misch wrote:
> For "\pset format wrapped", we only use $COLUMNS when the output is a
> tty. I'm thinking it's best, although not terribly important, to
> apply the same rule to this feature.
I think it does work that way. There is only one place where the
On Friday, November 04, 2011 6:04:02 pm Tom Lane wrote:
> I wrote:
> > A different line of thought is that there's something about these
> > specific source rows, and only these rows, that makes them vulnerable to
> > corruption during INSERT/SELECT. Do they by any chance contain any
> > values th
On 11/04/2011 05:01 PM, Tom Lane wrote:
Scott Mead writes:
I leave the waiting flag in place for posterity. With this in mind, is
the consensus:
RUNNING
or
ACTIVE
Personally, I'd go for lower case.
I was thinking it would be nice if this state looked like the
On Sat, Nov 05, 2011 at 04:53:56PM +0200, Peter Eisentraut wrote:
> On fre, 2011-11-04 at 07:34 -0400, Noah Misch wrote:
> > For "\pset format wrapped", we only use $COLUMNS when the output is a
> > tty. I'm thinking it's best, although not terribly important, to
> > apply the same rule to this fe
On mån, 2011-09-19 at 07:06 +0300, Peter Eisentraut wrote:
> I found a simpler way to get this working. Just hack up the catalogs
> for the new path directly. So I can now run this test suite against
> older versions as well, like this:
>
> contrib/pg_upgrade$ make installcheck oldsrc=somewhere
I wrote:
> A different line of thought is that there's something about these
> specific source rows, and only these rows, that makes them vulnerable to
> corruption during INSERT/SELECT. Do they by any chance contain any
> values that are unusual elsewhere in your table? One thing I'm
> wondering
Hi all,
The good news is that psql's backslash commands are becoming quite
thorough at displaying all information which could conceivably be of
interest about an object. The bad news is, psql's backslash commands
often produce a lot of noise and wasted output. (There was some
grumbling along these
On Fri, Nov 04, 2011 at 09:04:02PM -0400, Tom Lane wrote:
> Hah ... I have a theory.
>
> I will bet that you recently added some column(s) to the source table
> using ALTER TABLE ADD COLUMN and no default value, so that the added
> columns were nulls and no table rewrite happened. And that these
2011/10/28 Robert Haas :
> 2011/10/28 pasman pasmański :
>> I think, it be useful to include in version() function a hexadecimal
>> identifier of commit, for fast checkout to it in git.
>
> It's sort of impossible to make this accurate, though. You may have
> patched your tree but not created a co
Hi everyone,
I propose a patch that would allow optional "cleaning" of queries
tracked in pg_stat_statements, compressing the result and making it more
readable.
The default behavior is that when the same query is run with different
parameter values, it's actually stored as two separate queries (
2011/11/6 Tomas Vondra :
> Hi everyone,
> The patch implements a simple "cleaning" that replaces the parameter
> values with generic strings - e.g. numbers are turned to ":n", so the
> queries mentioned above are turned to
>
> SELECT abalance FROM pgbench_accounts WHERE aid = :n
>
> and thus tra
Dne 6.11.2011 03:16, Peter Geoghegan napsal(a):
> 2011/11/6 Tomas Vondra :
>> Hi everyone,
>
>> The patch implements a simple "cleaning" that replaces the parameter
>> values with generic strings - e.g. numbers are turned to ":n", so the
>> queries mentioned above are turned to
>>
>> SELECT abal
Attached patch adds a new function to the pageinspect extension for
measuring total free space, in either tables or indexes. It returns the
free space as a percentage, so higher numbers mean more bloat. After
trying a couple of ways to quantify it, I've found this particular
measure correlate
On Sat, Nov 5, 2011 at 2:46 PM, Jeff Janes wrote:
>> Moreover, there's no real guarantee that you're compiling from a git
>> tree at all; you could well be compiling from a tarball.
>>
>> All in all I feel like this is a solution in search of a problem.
>> People shouldn't be using anything other
19 matches
Mail list logo
