Because their SQL queries always seem to need a target object to select
from. i.e. SELECT NEXTVAL.foo isn't valid for Oracle 8/9.
It has been a long time since I've used Oracle, but shouldn't it be select
foo.nextval from dual?
Regards,
Mario Weilguni
Mario Weilguni wrote:
Because their SQL queries always seem to need a target object to select
from. i.e. SELECT NEXTVAL.foo isn't valid for Oracle 8/9.
snip
It has been a long time since I've used Oracle, but shouldn't it be select foo.nextval from dual?
Yep, that's sounds better. It's been a
On Sat, Jul 03, 2004 at 11:03:33AM -0400, Tom Lane wrote:
TransactionIdIsInProgress needs work/review; comments are off for one
thing, and it seems *way* too inefficient. Note it should be possible to
skip subtrans search for sufficiently old xacts (hm ... couldn't we skip
sinval search
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 Version database system
If you do that, does it make sense to display the full
Justin Clift wrote:
Christopher Kings-Lynne wrote:
snip
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
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
seen so far.
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, I'd
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
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
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.
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 Protocol
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
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
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
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
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
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}];
andrew$#
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 =
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 if
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 FORWARD
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 plan
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
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
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
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. Please
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 some
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
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
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 come
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 transaction Y
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 palloc
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 you
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 trusted
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
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 both
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 [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 created
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 *think* of
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
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
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,
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 and
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 transaction
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
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
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
[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
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 configure,
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 will
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
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
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
52 matches
Mail list logo
