PostgreSQLers,
I just ran into an issue where a client thought that autovacuum was
running but it wasn't. This is because it's not fatal when autovacuum
is on but stats_start_collector and/or stats_row_level is off. I
suspect that there's a reason that it's not fatal, so I thought that
it
On May 16, 2006, at 20:51, Tom Lane wrote:
Um ... design sanity and consistency, maybe? Not that I think PL/SQL
is any paragon of those virtues, but surely "we'll invent any feature
we feel like whether it's sane or not" is not a recipe for a
maintainable language.
Yes, sanity is important, I
On May 16, 2006, at 19:52, Tom Lane wrote:
Distant ancestors aren't particularly relevant here. What plpgsql
tries
to be is a ripoff^H^H^H^H^H^Hsincere flattery of Oracle's PL/SQL. If
modifying the loop variable is disallowed in PL/SQL, I'm all for
disallowing it in plpgsql, otherwise not.
On May 16, 2006, at 17:51, Jaime Casanova wrote:
i have posted a patch to add a BY clause to the for statement (integer
version), with the BY clause you can specify an increment value...
it's in the unapplied patches list waiting for review...
http://candle.pha.pa.us/mhonarc/patches/msg3.h
On May 16, 2006, at 17:02, Mark Dilger wrote:
It seems this has been answered before, by Tom Lane:
http://archives.postgresql.org/pgsql-novice/2006-04/msg00138.php
Ah, cool, then it *is* known.
Thanks,
David
---(end of broadcast)---
TIP 2: Do
On May 16, 2006, at 16:53, Mark Dilger wrote:
Sorry, I meant to say that it should only be a no-op according to
the language
specification, as I understand it. The fact that it works suggests
to me that
the implementation of PL/pgsql has been modified (or broken?).
Whether the
change is
On May 16, 2006, at 16:42, Mark Dilger wrote:
So I don't know why it works for you. I wrote the following, and
it also
increments the variable:
CREATE OR REPLACE FUNCTION weird () RETURNS SETOF INT AS $$
DECLARE
i integer;
BEGIN
i := 0;
return next i;
i = i + 1;
return ne
On May 16, 2006, at 16:30, Andrew Dunstan wrote:
It ought to be illegal to modify the loop control variable anyway,
IMNSHO - it certainly is in Ada, the distant antecedent of pl/pgsql.
I agree, but I must say that it's incredibly useful to be able to
increment by two as I go through a loop:
Hellow PostgreSQL hackers,
Quick question. Why does the 'i = i + 1' syntax work in this PL/pgSQL
function?
try=# CREATE OR REPLACE FUNCTION inc_by_two(
try(#upfrom int,
try(#upto int
try(# ) RETURNS SETOF INT AS $$
try$# BEGIN
try$# FOR i IN upfrom..upto LOOP
try$# RETUR
On Apr 21, 2006, at 13:54, Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Cool, thanks Bruce.
Best,
D
On Apr 3, 2006, at 14:37, Tom Lane wrote:
I would suggest handling this strictly as an addition to our
installation.sgml docs.
Finally got 'round to this. Patch attached. There are quite a few
environment variables in the list that Peter sent to me that I know
nothing about. These I've lis
On Apr 8, 2006, at 14:38, Tom Lane wrote:
It *is* documented: the manual lists the statements that affect FOUND,
and EXECUTE is not among them.
Whether it should be is another question, but that's a definition
disagreement (a/k/a enhancement proposal) not a bug.
I think that:
a. It should be
I had expected the FOUND PL/pgSQL variable to be set by an UPDATE
statement executed by an EXECUTE statement, but it doesn't appear to
work:
try=# drop table try;
DROP TABLE
try=# CREATE TABLE try (
try(# id integer
try(# );
CREATE TABLE
try=# INSERT INTO try VALUES (1);
INSERT 0 1
try=# CR
On Apr 3, 2006, at 13:49, David Wheeler wrote:
configure is autogenerated. You can't patch in there.
Oh. Duh. I'll grep for it.
Hrm. Is there a file somewhere from which the environment variable
section is generated? Or is it just created by autoconf?
Than
On Apr 3, 2006, at 13:44, Peter Eisentraut wrote:
configure is autogenerated. You can't patch in there.
Oh. Duh. I'll grep for it.
D
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/d
On Apr 3, 2006, at 13:37, Alvaro Herrera wrote:
Too verbose :-( How about putting the most important in configure,
and
the rest in a text file? Configure can then say "Some of them are
here,
the rest can be found in file such-and-such".
Yeah, I'll create a table for INSTALL.
Best,
Davi
On Apr 3, 2006, at 13:08, Peter Eisentraut wrote:
I'm not sure if this list is complete, but it's a good approximation:
Thanks. How's this, then?
Best,
David
--- configure 06 Mar 2006 09:41:42 -0800 1.485
+++ configure 03 Apr 2006 13:31:10 -0700
@@ -897,16 +897,36 @@
--with
On Apr 1, 2006, at 16:37, Tom Lane wrote:
Just to clarify my point: what'd make sense to me is to describe this
generic autoconf behavior, and maybe include a small table listing
some
of the more-likely-to-be-useful variables. ("configure --help"
already
does that, on a very small scale.)
On Apr 2, 2006, at 17:47, Robert Treat wrote:
ISTM that by any measure of the general population, David Wheeler is a
hard-core geek. :-) Actually by most measures of the "programming/
oss
community" he is a hard core geek. But he still got tripped up by
this. A
lot of people
On Apr 1, 2006, at 15:49, Peter Eisentraut wrote:
Well, you got one of them, but I still have my doubts about
"/usr/bin/per5.8.6".
LOL! God, what an oaf!
David
Index: doc/src/sgml/installation.sgml
===
RCS file: /projects/cvsroot
On Apr 1, 2006, at 15:39, David Wheeler wrote:
So, pray tell, what have I screwed up? I would of course be happy
to submit a corrected patch.
Sorry, I'm an idiot. New version attached.
Best,
David
Index: doc/src/sgml/installation
On Apr 1, 2006, at 06:58, Peter Eisentraut wrote:
Next time you submit a patch, please consider reading it before
sending
it out.
I just read the patch, and it looks fine to me. No typos that I
noticed. I might have screwed up the SGML stuff, but I know even less
about SGML than I do abo
On Mar 31, 2006, at 20:02, Tom Lane wrote:
You can give `configure' initial values for configuration
parameters
by setting variables in the command line or in the environment.
Here
is an example:
./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
This isn't super helpful, of course,
On Mar 31, 2006, at 16:01, Tom Lane wrote:
It seems rather pointless to document two instances of what is in fact
a generic autoconf-script behavior ...
I'm sorry to be such a moron about this, but what exactly is that
behavior? That you can specify an environment variable for whatever *
i
On Mar 31, 2006, at 15:52, Tom Lane wrote:
The more usual way to handle this sort of thing is to put each version
of perl in a different directory, and then you can alter PATH while
running configure to pick which one you want. I've got several
versions
of perl on this machine that I select
On Mar 31, 2006, at 12:40, Josh Berkus wrote:
In support of David's suggestion, I'll point out that most other OSS
software configuration scripts (Apache, PHP, etc.) I deal with
supports
the above syntax.
Yes, but even the environment variables get me what I want. I
therefore respectfully
On Mar 31, 2006, at 12:05, Seneca Cunningham wrote:
Like passing PERL=/usr/bin/perl5.8.6 to configure?
Is that currently supported? Because, if so, it's documented AFAICT.
Best,
David
---(end of broadcast)---
TIP 5: don't forget to increase yo
Dear PostgreSQL Hackers,
I recently ran into an issue where I was having trouble compiling
PostgreSQL with PL/Perl. Although Mac OS X 10.4 comes with a dynamic
Perl, I long ago compiled my own Perl, which is static. So /usr/bin/
perl was my static Perl, and /usr/bin/perl5.8.6 is the stock Pe
On Jul 15, 2005, at 5:13 PM, David Wheeler wrote:
No. I'm using the readline that comes with Tiger, FWIW. If you tell
me how to create a stack trace, I'll post it somewhere for you to
see. I don't know C, myself.
Didn't see a reply to this, but if it makes a differen
On Jul 15, 2005, at 4:55 PM, Tom Lane wrote:
This noise wasn't there ever before; I do not know if it's just that
Apple's tools got pickier recently, or if we've broken something.
I think they're new to Tiger, because I saw some warnings I ignored
when I built Pg.
Second, at exit from an
PostgreSQL hackers:
8.0.3 is working great for me on Mac OS X Tiger, but I do get a
segfault every time I exit pssql:
psql(7466) malloc: *** error for object 0x1806600: incorrect checksum
for freed object - object was probably modified after being freed,
break at szone_error to debug
psq
On Apr 26, 2005, at 5:02 PM, Jan Wieck wrote:
The multi-action rules usually come into play when someone attempts to
make join-views updatable. Not an easy problem, granted, but most of
the time I have found a combination of rules together with ON
UPDATE/DELETE CASCADE constraints or even user d
On Apr 26, 2005, at 2:58 PM, Tom Lane wrote:
... which indeed can be a feature, not a bug, depending on what you're
doing ...
Absolutely. An INSERT rule I have looks like this:
CREATE RULE insert_one AS
ON INSERT TO one WHERE NEW.id IS NULL
DO INSTEAD (
INSERT INTO _simple (id, guid, state, name,
On Apr 26, 2005, at 2:43 PM, Rob Butler wrote:
For this particular scenario, can't you just create
two ON DELETE rules? The first would delete from b,
the second from a. Perhaps an example with a scenario
like this can be added to the doc's?
No, that approach has the same problem. Once the first
On Apr 26, 2005, at 11:20 AM, Tom Lane wrote:
The problem is that OLD is effectively a macro for the view, and once
you've deleted one of the rows, that ID is no longer present anywhere
in
the view. Sometimes you can work around this by making the join an
outer join, but that's certainly a kluge.
On Apr 26, 2005, at 12:35 PM, Tom Lane wrote:
One possibility for an alternative mechanism is to allow triggers on
views --- but I'm not sure exactly how this would work, or if it would
solve all the problems. At the very least it would answer the "data
stability" issue, since I suppose the trigge
On Apr 25, 2005, at 11:00 PM, Tom Lane wrote:
DO INSTEAD means that the *original* query will not execute; it does
not suppress actions produced by other rules.
Ah!
If we did not define
it that way, I think your example would have to error out --- how
would you choose which INSTEAD rule wins?
The d
On Apr 25, 2005, at 11:37 PM, Tom Lane wrote:
(I have been thinking more and more that we should consider a wholesale
redesign of the rule mechanism, because it sure seems not to answer the
needs/expectations of a lot of people out there. But I am not talking
about marginal questions like what INS
On Apr 26, 2005, at 8:55 AM, Tom Lane wrote:
Well, they handle simple situations OK, but we keep seeing people get
burnt as soon as they venture into interesting territory. For
instance,
if the view is a join, you can't easily make a rule that turns a delete
into deletions of both joined rows. A
On Oct 18, 2004, at 3:12 PM, Bruce Momjian wrote:
It was just added to CVS!
Awesome!
Abhijit++
Bruce++
Tom++
Regards,
David
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Oct 14, 2004, at 6:50 PM, Abhijit Menon-Sen wrote:
I thought about that for a while, but I couldn't find anything that is
actually broken or confused by the patch. I could be missing something
obvious, though, so I'd appreciate another set of eyes looking at it.
Does anyone have any ideas?
Not I
On Oct 5, 2004, at 10:47 AM, Dann Corbit wrote:
Create a 64 bit hash (e.g. UMAC) of the prepared statement (removing
hardwired parameters as needed so that "SELECT Col1, col2 FROM
Some_Table where FOO = 'BAR'" becomes "SELECT COL1, COL2 FROM
SOME_TABLE WHERE FOO = ?", form consistent capitalizat
On Oct 5, 2004, at 9:59 AM, Abhijit Menon-Sen wrote:
I decided against bundling the two operations together. Here's a patch
to add PQprepare() and PQsendPrepare() in a fairly self-contained way.
Also attached is a test program à la testlibpq3.c that I used to test
the change. This should be all tha
On Sep 20, 2004, at 12:34 AM, Bruce Momjian wrote:
I think we should favor libpq usage wherever possible and only
re-implement it in the native language when required, like for
jdbc/java.
I think having all interfaces take advantage of libpq improvements and
features is a major win. If we need to
On Sep 19, 2004, at 9:13 PM, Abhijit Menon-Sen wrote:
OK, how about adding a PQprepare (PQcreatePrepared?) function like
this?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid *paramT
On Sep 18, 2004, at 1:09 PM, Oliver Jowett wrote:
Well, obviously. I haven't modified the backend code to accept
'unknown' in PREPARE..
Right, and that's what we're looking for.
My point was the client does *not* need to know the type inferred by
the PREPARE in the 'unknown' case to make use of t
On Sep 17, 2004, at 6:23 PM, Oliver Jowett wrote:
template1=> prepare s1(int) as select typname from pg_type where oid
= $1;
PREPARE
template1=> execute s1('16');
typname -
bool
(1 row)
You're still telling it the type via that int.
Regards,
David
---(end of broad
On Sep 17, 2004, at 2:21 PM, Tom Lane wrote:
Okay, here we have Bruce saying he'll add it to open items:
http://archives.postgresql.org/pgsql-hackers/2004-08/msg00147.php
so I guess it is the same thing. Good, that will give us some
political
cover for squeezing it into 8.0 ;-).
Ah, okay, so Jan
On Sep 17, 2004, at 1:54 PM, Tom Lane wrote:
David Wheeler <[EMAIL PROTECTED]> writes:
if I understand a previous post from you, this functionality should be
added to libpq, but you haven't had time and aren't sure what the API
should look like, anyway, is that correct?
Right. P
On Sep 17, 2004, at 1:32 PM, Tom Lane wrote:
Well, that's the problem: you can't. The SQL PREPARE command doesn't
have any provision for dealing with unspecified parameters. I think
this is reasonable since if it could, it would still have no way to
tell
you what it resolved the parameter types
On Wed, 15 Sep 2004 13:50:43 -0400, Tom Lane wrote:
> The describe statement part could be much trickier but DBD::Pg
doesn't really
> need that for basic functionality.
Doesn't it? I thought the problem was that they couldn't find out what
datatypes the parameters got resolved as. That may not
to go. To prevent this script
from
+# The startup bundle will now be ready to go. To prevent this script
from
# starting PostgreSQL at system startup, simply change that line in
-# /etc/hostconfig to:
+# /etc/hostconfig back to:
#
# POSTGRESQLSERVER=-NO-
#
--
David Wh
iable in /etc/hostconfig, as do other Darwin startup scripts.
I suggest that a new directory be created,
contrib/start-scripts/darwin, and that these two files be put into it.
Folks who want to use the script can read the comments inside it to
figure out how to use it.
Enjoy,
David
--
hard, and it
doesn't. So there's some time to play with this issue, I think.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
s that the nul character is legal in a byte sequence,
but if it's not properly escaped, it'll be parsed as the end of the
statement. Unfortunately, I think that it's a very tough problem to
solve.
David
--
David Wheeler AIM:
On Saturday, November 30, 2002, at 04:14 PM, Joe Conway wrote:
Not quite sure what you mean by delimiter -- are you referring to
double
escaping vs single escaping?
Oh crap, yes, that's exactly what I meant.
s/delimited/escaped/g;
Sorry. :-)
David
--
David Wh
d how bytea strings
are delimited, would it?
Best,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
J
as to
continue to allow strings to be converted to numbers on the back end.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: de
names like 'one', 'two', etc. Perhaps you can think of something
more descriptive.
No, I didn't write it. I just added the test to make sure that
SQL_BINARY threw an exception.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED]
,652977,00.asp
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
On Tuesday, Novembe
On Tuesday, November 26, 2002, at 07:12 AM, Neil Conway wrote:
Looks like a problem on your end...
Oh, the message finally got through, did it? I chatted with Bruce
yesterday and ran the tests again and they all passed.
Thanks,
David
--
David Wheeler
regression.diffs
Description: Binary data
regression.out
Description: Binary data
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
responsibility of the DBI
client to pass in data of the appropriate type.
Is this along the lines of what you're thinking, Tom?
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http:
63 matches
Mail list logo
