Attached is a (very small) patch to make analyze display some
interesting info in
verbose mode about the analyzed relation (pages, rows per block and rows ).
This is all available in the statistics catalog but I have found it
useful to see it appear as
you run...
mods to :
src/backend/commands
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I didn't like the functions ending in _ext. I renamed them to _pp for
> pretty print. Patch attached and applied.
Seems to be shy a catversion bump; since you have just made an
incompatible change in the internal-function-names array, one is needed.
B
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can I get some comments on this?
It's far from ready for prime time :-(
The main problem with it is it's doing the wrong things in the wrong
places. The key part of the patch is a hack in parse_expr.c to
transform "WHERE CURRENT OF cursor" into "WHERE
Didn't Tom already apply that???
Chris
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>
Cc: "Andreas Pflug" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, July 31, 2003 12:52 PM
Subject: Re: [PATCHES] ruleutils with pretty-print
Patch applied, modified by Tom and myself.
---
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >Andreas, looks good, but I need a diff -c, context diff.
> >
> >
> >
> Hi Bruce,
> I intentionally only attached only non-con
I didn't like the functions ending in _ext. I renamed them to _pp for
pretty print. Patch attached and applied.
---
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > I recoded the stuff as Tom recommended, le
Patch applied. Thanks.
---
Rod Taylor wrote:
-- Start of PGP signed section.
> contraints -> constraints
[ Attachment, skipping... ]
-- End of PGP section, PGP failed!
--
Bruce Momjian| http:/
Can I get some comments on this? I know the work was completed
pre-feature freeze, but submitted only recently.
---
Gavin Sherry wrote:
> Attached is a patch implementing updatable cursors in HEAD. Regression
> test and doc
Tom, have you considered using PGC_USERLIMIT for the existing
default_transaction_read_only variable? You could allow admins to turn
it on and off, but non-admins could only turn it on.
---
Tom Lane wrote:
> Sean Chittenden
If we change default_transaction_read_only to PGC_USERLIMIT, the
administrator can turn it on and off, but an ordinary user can only turn
it on, but not off.
Would that help?
---
Sean Chittenden wrote:
-- Start of PGP sig
> >> I'm not objecting to the idea of being able to make users
> >> read-only. I'm objecting to using GUC for it. Send in a patch
> >> that, say, adds a bool column to pg_shadow, and I'll be happy.
>
> > How is that any different than ALTER USER [username] SET
> > jail_read_only_transactions TO
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> I'm not objecting to the idea of being able to make users read-only.
>> I'm objecting to using GUC for it. Send in a patch that, say, adds
>> a bool column to pg_shadow, and I'll be happy.
> How is that any different than ALTER USER [username] SET
>
Does anyone have any outstanding patches they expected would be applied
for 7.4? I think everything in my inbox has been dealt with, but I
might have missed something.
Bruce is not done generating release notes, so we probably will not have
a formal beta package ready until Friday. However, CVS
> >> It's not intended to be a security measure, and I would strongly
> >> resist any attempt to make it so along the lines you propose.
>
> > Intended or not, it does work.
>
> No, you just haven't thought of a way to get around it yet. When
> you do think of one, you'll be wanting us to contor
Andreas Pflug <[EMAIL PROTECTED]> writes:
> I recoded the stuff as Tom recommended, leaving the non-pretty version
> function names as they used to be, inventing new pg_get__ext
> functions for the extended stuff, and pushing the code down into
> pg_get__worker functions when needed. We
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> It's not intended to be a security measure, and I would strongly
>> resist any attempt to make it so along the lines you propose.
> Intended or not, it does work.
No, you just haven't thought of a way to get around it yet. When you do
think of one,
> > > Um, why not make it an actual full blown security feature by
> > > applying the following patch? This gives PostgreSQL real read
> > > only transactions that users can't escape from. Notes about the
> > > patch:
> >
> > Way nifty.
> >
> > I vote in favor of this patch (suitably documen
> > Um, why not make it an actual full blown security feature by
> > applying the following patch? This gives PostgreSQL real read
> > only transactions that users can't escape from. Notes about the
> > patch:
>
> Way nifty.
>
> I vote in favor of this patch (suitably documented & debugged)
> >> I would NOT call it a "security" provision, as it is fairly
> >> easily defeated using SET TRANSACTION.
>
> > Um, why not make it an actual full blown security feature by
> > applying the following patch?
>
> It's not intended to be a security measure, and I would strongly
> resist any attem
Joe Conway <[EMAIL PROTECTED]> writes:
> Here's a patch that replaces the ERROR with a NULL return value when an
> element in an array expression is NULL.
Applied. I also added a comment to remind us to change
contain_nonstrict_functions() when ARRAY's behavior is changed again.
Sean,
> Um, why not make it an actual full blown security feature by applying
> the following patch? This gives PostgreSQL real read only
> transactions that users can't escape from. Notes about the patch:
Way nifty.
I vote in favor of this patch (suitably documented & debugged) for 7.5.
-
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> I would NOT call it a "security" provision, as it is fairly easily
>> defeated using SET TRANSACTION.
> Um, why not make it an actual full blown security feature by applying
> the following patch?
It's not intended to be a security measure, and I wou
22 matches
Mail list logo
