On Mon, 5 Jul 2004, Alvaro Herrera wrote:
> > begin/end because they are already in an explicit/implicit transaction
> > by default... How is the user/programmer to know when this is the case?
>
> I'm not sure I understand you. Of course you can issue begin/end. What
> you can't do is issue be
So what are we going to do about it?
Fix it, of course.
I just wanted to make sure it happened :)
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> In a quick glance this code seems close to completely brain dead :-(
> So what are we going to do about it?
Fix it, of course.
(Note I only fixed the parenthesization, I take no responsibility for
the still-pretty-brain-dead layout.)
need_paren = (PRETTY_PAREN(context) ?
!IsA(op->rarg, RangeTblRef) : true);
In a quick glance this code seems close to completely brain dead :-(
For one thing, why isn't it making separate determinations about whether
the left and right inputs of the UNION (resp INTE
On Fri, 2 Jul 2004, Joshua D. Drake wrote:
So we have three choices as I see it:
1) revert the change
2) require some minimally recent version of perl
3) fix the issue in place
Preferences?
Joshua/Andrew -- do you want to take a shot at making this work on perl
5.00503?
I personally don't have an
On Sat, Jul 03, 2004 at 02:32:44AM -0500, Thomas Swan wrote:
> Alvaro Herrera wrote:
> >What I'd like to do is start the transaction block before the function
> >is called if we are not in a transaction block. This would mean that
> >when the function calls BEGIN it won't be the first one -- it w
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> I've reverted the part of this patch that attempted to make plperl use
>> rpath, because it doesn't actually work...
> Is there a more portable way of doing this, via configure maybe?
It doesn't look to me like we handle rpath switch syntax via config
[redirected to -hackers]
Tom Lane wrote:
[EMAIL PROTECTED] (Joe Conway) writes:
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's
plperlNG. Review and minor cleanup/improvements by Joe Conway.
I've reverted the part of this patch that attempted to make plperl use
On Mon, 2004-07-05 at 23:27, Steve Holdoway wrote:
> Hi folks,
>
> I'm trying to seriously restrict what a particular user can see within a
> database. Using various schemas, rules, groups and grants, I've managed
> to restrict them to only being able to _do_ what I want them to, but
> they can
Alvaro Herrera wrote:
On Mon, Jul 05, 2004 at 05:13:23PM -0400, Bruce Momjian wrote:
Alvaro Herrera wrote:
On Sun, May 02, 2004 at 07:50:46PM -0400, Tom Lane wrote:
It's entirely likely that ecpg's derivative of the backend's datetime
modules contains lots and lots of memory leaks, since AFAIK the
Simon Riggs wrote:
On Mon, 2004-07-05 at 23:40, Mike Mascari wrote:
hmmm...not sure I know what you mean.
It is very-very-close-to-impossible to edit the transaction logs
manually, unless some form of special-format editor were written for the
purpose.
Is it clear that the PITR features are comp
On Mon, 2004-07-05 at 23:40, Mike Mascari wrote:
> Simon Riggs wrote:
>
> >
> > ...Nobody is shouting YES, so its a dodo...
>
> The point at which the above process becomes
> too complex (or less than obvious) for hand-recovery is precisely
> when unforeseen consequences of nixing a single tr
On Mon, 2004-07-05 at 22:46, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Should we use a different datatype than time_t for the commit timestamp,
> > one that offers more fine grained differentiation between checkpoints?
>
> Pretty much everybody supports gettimeofday() (time_t a
Steve Holdoway wrote:
Hi folks,
I'm trying to seriously restrict what a particular user can see within
a database. Using various schemas, rules, groups and grants, I've
managed to restrict them to only being able to _do_ what I want them
to, but they can still _see_ the rest of the schemas, sys
Simon Riggs wrote:
On Mon, 2004-07-05 at 22:30, Tom Lane wrote:
...Nobody is shouting YES, so its a dodo...
I can imagine a scenario where the junior DBA accidentally deletes
all rows from some obscure table that wouldn't have logical
implications for later transactions. But I suspect most people
Alvaro Herrera wrote:
Well, the proposal of implementing it like holdable cursors means using
a Materialize node which, if I understand correctly, means taking the
whole result set and storing it on memory (or disk). So the same
question arises: why bother implementing that at all? Of course the
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
That would work. You'd need two state flags instead of just one, but
that doesn't seem bad.
'splain please :-)
Maybe you weren't thinking of the same thing, but what I was imagining
was one state fla
Hi folks,
I'm trying to seriously restrict what a particular user can see within a
database. Using various schemas, rules, groups and grants, I've managed
to restrict them to only being able to _do_ what I want them to, but
they can still _see_ the rest of the schemas, system tables, etc. I've
On Mon, 2004-07-05 at 22:30, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > ...While recovering, it is very straightforward to simply ignore every
> > record associated with one (or more) transactions. That gives us the
> > ability to recover "all apart from txnid X".
>
> Don't even
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> That would work. You'd need two state flags instead of just one, but
>> that doesn't seem bad.
> 'splain please :-)
Maybe you weren't thinking of the same thing, but what I was imagining
was one state flag to remember that you'd cre
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The thing is that unlike TCL we have one interpreter for both trusted
and untrusted cases.
My thinking is to factor out all the code that only applies to trusted
cases from the interpreter init code, and only call it if we try
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Currently we have this in plperl.c:
"require Safe;"
I am thinking of submitting a patch to replace this with "use Safe
2.09;" to enforce use of a version without the known vulnerability.
This would break bot
I just reproduced this problem when returning
a composite and NOT as SETOF composite.
An assumption is being made that if the return
value is a composite, that it must be part of a set.
This is incorrect.
Test case available on request--if you don't have
one already.
Spoke with Andrew wrt on #po
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The thing is that unlike TCL we have one interpreter for both trusted
> and untrusted cases.
> My thinking is to factor out all the code that only applies to trusted
> cases from the interpreter init code, and only call it if we try to
> compile a tr
On Tue, Jul 06, 2004 at 08:45:52AM +1200, Oliver Jowett wrote:
> Buffering *all* the ResultSet data client-side isn't an option --
> cursors are used specifically to handle resultsets that don't fit into
> heap on the client side. And implementing a disk cache or similar a)
> doesn't work if yo
Simon Riggs <[EMAIL PROTECTED]> writes:
> Should we use a different datatype than time_t for the commit timestamp,
> one that offers more fine grained differentiation between checkpoints?
Pretty much everybody supports gettimeofday() (time_t and separate
integer microseconds); you might as well us
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I wonder why is this? Is there some limitation to using palloc outside
> the backend itself? I ask because I have considered using it outside
> Postgres several times (a consideration that has never materialized
> yet), and I wonder if it needs somethi
On Mon, Jul 05, 2004 at 05:13:23PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > On Sun, May 02, 2004 at 07:50:46PM -0400, Tom Lane wrote:
> >
> > > It's entirely likely that ecpg's derivative of the backend's datetime
> > > modules contains lots and lots of memory leaks, since AFAIK the
Simon Riggs <[EMAIL PROTECTED]> writes:
> ...While recovering, it is very straightforward to simply ignore every
> record associated with one (or more) transactions. That gives us the
> ability to recover "all apart from txnid X".
Don't even *think* of going there.
What will happen when transacti
On Tue, Jul 06, 2004 at 08:45:52AM +1200, Oliver Jowett wrote:
> This is a non-starter for JDBC: it has no control over when an
> application decides to access a ResultSet in a way that results in a
> FETCH of new data.
>From what you're telling me, I'm not sure I like JDBC! Why did they com
Alvaro Herrera wrote:
> On Sun, May 02, 2004 at 07:50:46PM -0400, Tom Lane wrote:
>
> > It's entirely likely that ecpg's derivative of the backend's datetime
> > modules contains lots and lots of memory leaks, since AFAIK the palloc
> > infrastructure is not there in the ecpg environment :-(.
>
>
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Currently we have this in plperl.c:
"require Safe;"
I am thinking of submitting a patch to replace this with "use Safe
2.09;" to enforce use of a version without the known vulnerability.
This would break both plperl and plperlu o
Jeroen T. Vermeulen wrote:
That makes me wonder why people want to maintain transactionality w.r.t.
nested transactions but not with "outer" ones. Odd!
Yep.
But then the FETCH should still occur before the transaction as far as I'm
concerned. You fetch a batch (if it fails, you terminate) and *tr
Taking advantage of the freeze bubble allowed us... there are some last
minute features to add.
Summarising earlier thoughts, with some detailed digging and design from
myself in last few days - we're now in a position to add Point-in-Time
Recovery, on top of whats been achieved.
The target for
On Sun, May 02, 2004 at 07:50:46PM -0400, Tom Lane wrote:
> It's entirely likely that ecpg's derivative of the backend's datetime
> modules contains lots and lots of memory leaks, since AFAIK the palloc
> infrastructure is not there in the ecpg environment :-(.
I wonder why is this? Is there som
I'm looking at a couple of features that are possible to add.
>From what people have said before on list, one of the useful features of
PITR is to recover from rogue transactions.
I have a suggestion that I'd like some considered thought on. I've given
it a couple of weeks thought. My first incli
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Currently we have this in plperl.c:
> "require Safe;"
> I am thinking of submitting a patch to replace this with "use Safe
> 2.09;" to enforce use of a version without the known vulnerability.
This would break both plperl and plperlu on older Perls.
Joshua D. Drake wrote:
Currently we have this in plperl.c:
"require Safe;"
I am thinking of submitting a patch to replace this with "use Safe
2.09;" to enforce use of a version without the known vulnerability.
Any objections?
I have none, except will 2.09 work with 5.00503?
I will see about
Currently we have this in plperl.c:
"require Safe;"
I am thinking of submitting a patch to replace this with "use Safe
2.09;" to enforce use of a version without the known vulnerability.
Any objections?
I have none, except will 2.09 work with 5.00503?
cheers
andrew
There is a known security issue with the perl Safe module versions up to
and including 2.07 (and 2.08 had a life of 1 day before 2.09 was
released). see
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1323
Currently we have this in plperl.c:
"require Safe;"
I am thinking of submitting a
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Can anyone suggest why I might be seeing this effect (each notice comes
out once per row plus once per function call)
It looks like you're executing the whole function body once per physical
call, which is certainly not a good pla
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Can anyone suggest why I might be seeing this effect (each notice comes
> out once per row plus once per function call)
It looks like you're executing the whole function body once per physical
call, which is certainly not a good plan for a function ret
On Tue, Jul 06, 2004 at 12:17:50AM +1200, Oliver Jowett wrote:
> 7.4/7.5's behaviour leaves the cursor state unchanged by the rollback:
>
> DECLARE foo CURSOR WITH HOLD FOR SELECT * FROM sometable
>
> BEGIN
>FETCH FORWARD 10 FROM foo -- returns rows 1..10
> ROLLBACK
>
> BEGIN
>FETCH
OK, thanks. I see where the problem is. We'll fix the SRF code.
cheers
andrew
Darko Prenosil wrote:
Because that is exactly count of "tstset" function being called. Set returning
functions are called recursively until SRF_RETURN_DONE is returned, and that
in You case means until last row is fetch
Because that is exactly count of "tstset" function being called. Set returning
functions are called recursively until SRF_RETURN_DONE is returned, and that
in You case means until last row is fetched.
When You programming functions in "C", there is SRF_ISFIRST_CALL function that
returns "true"
I am unable to reproduce this effect.
The script below (slightly adapted from yours) runs just fine repeatedly
in the same session with expected results.
create or replace function plperl_bug1( )
returns text as
$$
my $qry = 'select * from pg_user';
elog NOTICE, "Good Query is: $qry";
my $rv =
Can anyone suggest why I might be seeing this effect (each notice comes
out once per row plus once per function call)
thanks
andrew
andrew=# create function tstset() returns setof tst language plperl as $$
andrew$# elog(NOTICE,"tstset called");
andrew$# return [{i=>1,v=>"one"},{i=>2,v=>"two"}];
a
Disregard,
Was sent to postgresql.com
...
-Original Message-
From: John Hansen
Sent: Monday, July 05, 2004 11:21 PM
To: [EMAIL PROTECTED]
Subject: Relay Access Denied
Seems mail.postgresql.org refuses mail for [EMAIL PROTECTED]
at present?
---(end of broadcas
Yes, The API is changed slightly, which I should have made clear.
The number of rows is reported in a member called 'processed'. If actual
data is returned (i.e. from a select), then that data is returned in the
'rows' member (it will be a ref to an array of refs to hash.
Run this sample script
Bruce Momjian wrote:
> Because I am traveling, I will no longer be reviewing and applying
> patches until I return on July 3. Tom will take over most of this duty.
> I will check things once I get back to be sure everything got in just so
> Tom can relax knowing someone will make sure nothing was
Seems mail.postgresql.org refuses mail for [EMAIL PROTECTED]
at present?
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can
Jeroen T. Vermeulen wrote:
Well, I'd say DEALLOCATE is implicitly lumped in with PREPARE. But as for
FETCH, are you referring to cursors that live outside transactions (but get
manipulated inside transactions)? Are those implemented yet and if so, how
does FETCH work there?
I'm thinking WITH HOL
Najib Abi Fadel wrote:
Hi
i have an ordered table of dates let's say:
No you don't (tables aren't ordered), and I think that's what's going to
cause you trouble.
1/1/2004
8/1/2004
15/1/2004
29/1/2004
5/2/2004
12/2/2004
I am searching for a way to have the minimum date and maximum date for
date
On Mon, Jul 05, 2004 at 11:44:08PM +1200, Oliver Jowett wrote:
> > SQL session - temp tables, session variables, database contents
> > Interchange - encoding & representation
> > Protocol - COPY, bind/execute &c.
> > Connection - socket stuff
> >Transactions come into play at the
Jeroen T. Vermeulen wrote:
So perhaps we should be distinguishing several
layers in a session's state, along the lines of:
SQL session - temp tables, session variables, database contents
Interchange - encoding & representation
Protocol - COPY, bind/execute &c.
Connec
On Mon, Jul 05, 2004 at 10:21:26AM +1200, Oliver Jowett wrote:
> It certainly affects the JDBC driver -- the native String representation
> in Java is UTF-16, so the driver transcodes between that and
> client_encoding for parameterized queries and query results involving
> strings.
Oops, ye
Dear friends,
This is an off-topic message about a new project called FreeOSZoo involving
two pgAdmin member, Jean-Michel and Raphaël.
You can visit our site on:
http://www.freeoszoo.org
We provide packages for QEMU, a fast PC emulator for GNU/Linux, Win32 and Mac
OS X. The packages and instru
Andrew McMillan wrote:
On Sun, 2004-07-04 at 13:11 +0200, Andreas Pflug wrote:
That's right, and initially they will only serve MySQL, but it will be
extendable to support any db system. It will be GPL (or licenseable, but
since it's a tool and not a platform IMHO GPL is ok).
If things work ou
On Sun, 2004-07-04 at 13:11 +0200, Andreas Pflug wrote:
>
> That's right, and initially they will only serve MySQL, but it will be
> extendable to support any db system. It will be GPL (or licenseable, but
> since it's a tool and not a platform IMHO GPL is ok).
> If things work out as they seem,
Tom Lane wrote:
BTW, I've been more or less ignoring the nearby debate about whether
cursors ought to roll back at subxact abort or not, because right now
I don't know how to implement *either* behavior. Unless we have
credible theories about how to implement both, it's a bit useless to
debate whi
> begin;
> declare cursor c ...;
> fetch 1 from c; -- returns tuple 1
> begin;
> fetch 1 from c; -- returns tuple 2
> rollback;
> fetch 1 from c; -- returns tuple 1 again
>
> This is mightly ugly but I think it's the most usable of the options
> see
Justin Clift wrote:
Christopher Kings-Lynne wrote:
Anyone who's writing queries that are examing the schema of the
database is by definition not a newbie...
By newbie here, I mean someone who's a PG "newbie" but has a
reasonable understanding of databases (i.e. Oracle, etc) would
generally fin
Kaare Rasmussen wrote:
That would be great news indeed. Currently there is a lack of an Open Source
heavy duty database design tool.
If it can be compared to Erwin, it will be a big win - if it can do both
reverse and forward engineering of databases.
It's is aimed to replace ErWIN or Ap
On Sat, 2004-07-03 at 15:26, Michael Brusser wrote:
> > Would anybody object to adding an extra line at startup that shows the
> > version number of the database system?
> >
> > Message suggestion:
> > Starting PostgreSQL database system
> >
> If you do that, does it make sense to display the f
64 matches
Mail list logo
