Why does the first query below return the same value for each row
while the second query returns random values? Planner optimization?
test=> SELECT ARRAY(SELECT random()) FROM generate_series(1, 5);
?column?
-
{0.269273371561092}
{0.269273371561092}
{0.26927337
Joshua D. Drake wrote:
Hello,
I have negotiated with the author of pl/Ruby to release plRuby under the
PostgreSQL license. The reason I did this is the following:
What does everybody think?
I think you should take a closer look at PL/Java for the following reasons:
1. The number of followe
On E, 2005-08-15 at 10:30 -0700, Joshua D. Drake wrote:
> Hello,
>
> I have negotiated with the author of pl/Ruby to release plRuby under the
> PostgreSQL license.
Good!
> The reason I did this is the following:
>
> 1. I felt we needed a truly OO language in core.
> 2. plPython isn't really m
Greg Stark <[EMAIL PROTECTED]> writes:
> So why bother with driving multiple invocations of psql under
> Expect. Just use DBD::Pg to open as many connections as you want and
> issue whatever queries you want.
The bit that I think is missing in DBI is "issue a command and don't
wait for the result
Tom Lane <[EMAIL PROTECTED]> writes:
> [ digs... ] It looks like what I was remembering is
> http://search.cpan.org/~lbrocard/Test-Expect-0.29/lib/Test/Expect.pm
> which seems to leave all the interesting problems (like driving more
> than one program-under-test) to the user's own devices. Sigh
Bruce Momjian writes:
> Tom Lane wrote:
>> ... but everybody else is locked out completely, because the ALTER takes
>> an exclusive lock on the table. It's a bit misleading to describe that
>> as a local change.
> The pre-8.1 method was to UPDATE pg_class.reltriggers = 0. Would that
> allow con
On Mon, 15 Aug 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
I'd vote to get rid of it ... the concept of 'registering' might throw
some for a loop ...
Works for me; will do that in the 7.3 and 7.2 branches.
It'd still be a good idea to put in some redirects to make th
I'd vote to get rid of it ... the concept of 'registering' might throw
some for a loop ...
On Mon, 15 Aug 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Mon, 15 Aug 2005, Robert Treat wrote:
I installed 7.3.10 from source the other day, and noticed that at the end
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I'd vote to get rid of it ... the concept of 'registering' might throw
> some for a loop ...
Works for me; will do that in the 7.3 and 7.2 branches.
It'd still be a good idea to put in some redirects to make those old
URLs do something again.
Tom Lane wrote:
> Bruce Momjian writes:
> > Oh, and one trick for disabling triggers in a single session is to do
> > this:
>
> > BEGIN WORK;
> > ALTER TABLE xx DISABLE TRIGGER ALL
> > ...
> > ALTER TABLE xx ENABLE TRIGGER ALL
> > COMMIT WORK;
>
> > In this case, the triggers
Bruce Momjian writes:
> Oh, and one trick for disabling triggers in a single session is to do
> this:
> BEGIN WORK;
> ALTER TABLE xx DISABLE TRIGGER ALL
> ...
> ALTER TABLE xx ENABLE TRIGGER ALL
> COMMIT WORK;
> In this case, the triggers are disabled just for that
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 15 Aug 2005, Robert Treat wrote:
>> I installed 7.3.10 from source the other day, and noticed that at the end of
>> initdb it told me I could register my install and check out the mailing
>> lists, both a 404'd web pages. Does anyone think we
My recollection is that that change was way too invasive to be
reasonable for a back-port. The solutions used for circular reference
situations (various ALTER commands) probably don't exist very far back
anyway.
Nah, all you need to do is take the 8.0 pg_dump, hard-code that
--use-set-session-
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Is there any call to backport the pg_dump object sorting improvements?
My recollection is that that change was way too invasive to be
reasonable for a back-port. The solutions used for circular reference
situations (various ALTER commands) pro
On Mon, 15 Aug 2005, Robert Treat wrote:
On Monday 15 August 2005 13:06, Tom Lane wrote:
The core committee has agreed that we need to do a set of releases
in the back branches soon --- certainly 8.0 has accumulated a critical
mass of changes since 8.0.3, and probably there's enough to justify
Yeah, I suppressed that alternative a few weeks ago, thinking that it
was not sensible since we don't really support having indexes owned
by anyone except the owner of the parent table. Not sure what to do
about the fact that pg_dump has been emitting it though. Maybe reduce
the error to a warnin
Satoshi Nagayasu wrote:
> Bruce Momjian wrote:
> > I am not sure what to do with this patch. It is missing dump
> > capability, there is no clause to disable all triggers on a table, and
> > it uses a table owner check when a super user check is required (because
> > of referential integrity).
> >
The core committee has agreed that we need to do a set of releases
in the back branches soon --- certainly 8.0 has accumulated a critical
mass of changes since 8.0.3, and probably there's enough to justify
updates of the 7.* branches too. We hope to get these out sometime
next week, after the fir
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm pretty sure there are re-implementations of Expect out there that
>> don't use Tcl; would you be happier with, say, a perl-based tool?
> Yes, because we already have a dependency on perl. But don't be
> surprised if we can't find
Tom Lane wrote:
Expect is very cool, but it would impose an extra dependency on tcl that
we don't now have for building and testing,
True. I was pointing to it more as an example of the sorts of tools
people have built for this type of problem.
I'm pretty sure there are re-implementat
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Or else a harness that operates at the library/connection level rather
> than trying to control a tty app.
Right. What is sort of in the back of my mind is a C program that can
open more than one connection, and it reads a script that tells it
"fire t
Tom Lane wrote:
What we really need is a test program that can issue a command on one
connection (perhaps waiting for it to finish, perhaps not) and then
issue other commands on other connections, all according to a script.
I am unsure that the existing pg_regress infrastructure is the right
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Hiroki Kataoka wrote:
> Hi all,
>
> This small patch improves the performance of INSERT and UPDATE. By my
> machin
On Mon, Aug 15, 2005 at 10:37:06PM +, Matt Miller wrote:
> > Perhaps we should look at Expect or something similar.
>
> Where can I get more info on Expect?
http://www.google.com/
:-)
Or here:
http://expect.nist.gov/
--
Michael Fuhr
---(end of broadcast)-
> > Perhaps we should look at Expect or something similar.
>
> Where can I get more info on Expect?
I think I found it:
http://expect.nist.gov/
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgres
> What we really need is a test program that can issue a command on one
> connection (perhaps waiting for it to finish, perhaps not) and then
> issue other commands on other connections, all according to a script.
It seems to me that this is what contrib/dblink could allow, but when I
presented th
Matt Miller <[EMAIL PROTECTED]> writes:
> The attached patch allows src/test/regress/pg_regress.sh to recognize
> lines that begin with "curr_test:" in the schedule file. Tests named on
> such a line are run concurrently across multiple connections.
This doesn't seem like any advance over the exi
On Mon, 2005-08-08 at 16:59 -0400, Tom Lane wrote:
> Matt Miller <[EMAIL PROTECTED]> writes:
> > I want to write some regression tests that confirm the behavior of
> > multiple connections simultaneously going at the same tables/rows. Is
> > there something like this already, e.g. in src/test/regr
Am Montag, den 15.08.2005, 10:30 -0700 schrieb Joshua D. Drake:
> Hello,
>
> I have negotiated with the author of pl/Ruby to release plRuby under the
> PostgreSQL license. The reason I did this is the following:
>
> 1. I felt we needed a truly OO language in core.
> 2. plPython isn't really movi
Bruce Momjian wrote:
I do think plruby would be a nice addition to core.
Me too. It needs some work (didn't build out of the box for me against
cvs tip).
FYI, I have a backburner project to create PL/JS, which would a
trusted-only language - JS could actually be quite a nice fit, and
Robert Treat wrote:
I installed 7.3.10 from source the other day, and noticed that at the end of
initdb it told me I could register my install and check out the mailing
lists, both a 404'd web pages. Does anyone think we should update these older
versions with more current information?
On Monday 15 August 2005 13:06, Tom Lane wrote:
> The core committee has agreed that we need to do a set of releases
> in the back branches soon --- certainly 8.0 has accumulated a critical
> mass of changes since 8.0.3, and probably there's enough to justify
> updates of the 7.* branches too. We
Bruce Momjian wrote:
I do think plruby would be a nice addition to core. I also assume this
is for the 8.2 release, not 8.1.
Yes that would be my assumption as well.
Sincerely,
Joshua D. Drake
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replicatio
I do think plruby would be a nice addition to core. I also assume this
is for the 8.2 release, not 8.1.
---
Joshua D. Drake wrote:
> >
> > Hmm. I read this as
> >
> > Problem: not enough hackers to maintain our PL l
Hmm. I read this as
Problem: not enough hackers to maintain our PL languages.
Proposed solution: add more PL languages.
Somehow this doesn't seem quite right.
Although I see your point, that actually wasn't my point. My point was
that I felt we need a good well respected
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> I have negotiated with the author of pl/Ruby to release plRuby under the
> PostgreSQL license. The reason I did this is the following:
> 1. I felt we needed a truly OO language in core.
> 2. plPython isn't really moving forward and has the whole
>
Hello,
I have negotiated with the author of pl/Ruby to release plRuby under the
PostgreSQL license. The reason I did this is the following:
1. I felt we needed a truly OO language in core.
2. plPython isn't really moving forward and has the whole
trusted/untrusted issue.
Now anyone who know
The core committee has agreed that we need to do a set of releases
in the back branches soon --- certainly 8.0 has accumulated a critical
mass of changes since 8.0.3, and probably there's enough to justify
updates of the 7.* branches too. We hope to get these out sometime
next week, after the firs
Tom Lane wrote:
I've been testing this patch a bit, and I'm unable to measure any
consistent improvement in pgbench times (sometimes it seems to win,
and some other times it doesn't). And gprof still swears up and down
that PageAddItem is only about 0.1% of the runtime, which would make
it impos
* Stefan Kaltenbrunner ([EMAIL PROTECTED]) wrote:
> ALTER ROLE seems to support ALTER ROLE ROLE - but that
> form is not mentioned in the docs:
It's not really encouraged and is more because (iirc) that's what 'alter
group' did.
> ALTER ROLE IN ROLE (undocumented but seems logical to try
> be
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> To accomplish this I need to add following function into
> storage/ipc/procarray.c. This is similar to BackendPidGetProc() except
> that it accepts xid as an argument. Any objection?
> if (xid == 0) /* never match dummy PGP
pg_dump is STILL emiting alter index.
ISTM we shou make it a warning AND remove it from pg_dump
Regards
On Mon, 15 Aug 2005, Tom Lane wrote:
> Date: Mon, 15 Aug 2005 09:54:12 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list
> Subject: Re: [HACKERS] ALTER IN
> Should this functionality be moved into the backend? When?
Since feature freeze for 8.1 has been already made, I think this
should be into 8.2 or later if necessary.
BTW, I have modified pgrowlocks so that it shows pids:
test=# select * from pgrowlocks('t1');
locked_row | lock_type | locker
> Is there a way to detect where is memory hold ?
Look at postgis code. We constructed rtree_gist index over 1e9 rows (on 8.0
pgsql).
Is there an index-specific memory context for use
to early release memory blocks allocated during
operations (didn't see any use of memory contexts
in the con
ohp@pyrenet.fr writes:
> It seems that ALTER INDEX foo OWNER TO bar; doesn't work anymore.
> The error is foo is not a table or a view.
Yeah, I suppressed that alternative a few weeks ago, thinking that it
was not sensible since we don't really support having indexes owned
by anyone except the own
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> I played around with roles a bit today and noticed some minor things:
> ALTER ROLE seems to support ALTER ROLE ROLE - but that
> form is not mentioned in the docs:
There are some cases that work, but are not documented (or supported),
as a resu
Hi all,
It seems that ALTER INDEX foo OWNER TO bar; doesn't work anymore.
The error is foo is not a table or a view.
That's not a problem per se, but pg_dump continues to issue those
commands.
This is since a few weeks on CVS.
Regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00
Hi!
I played around with roles a bit today and noticed some minor things:
ALTER ROLE seems to support ALTER ROLE ROLE - but that
form is not mentioned in the docs:
playground=# CREATE ROLE myrole;
CREATE ROLE
playground=# CREATE ROLE myrole2;
CREATE ROLE
playground=# ALTER ROLE myrole ROLE myr
48 matches
Mail list logo
