Jan Wieck wrote:
But what if they decide to allow
LOOP
-- ...
IF condition THEN
EXIT;
END LOOP;
at some point? There you'd get ambiguity.
ISTM this would be ambiguous in any case:
IF condition1 THEN
foo;
IF condition2 THEN
bar;
END IF;
-Neil
On Thu, 23 Jun 2005, Tom Lane wrote:
both directions (X and Y) for 1-D inquiries. The same problems exist in
the contrib/rtree_gist implementation, because it just copied the r-tree
logic without inquiring too closely into it :-(
you're right, it was the beginning of our GiST experiments. Lat
FYI, TODO has:
* Fix incorrect rtree results due to wrong assumptions about "over"
operator semantics [rtree]
---
Tom Lane wrote:
> Hmmm ... just when you thought it was safe to go back in the water ...
>
On Wednesday 22 June 2005 11:41, Neil Conway wrote:
> Andrew Dunstan wrote:
> > But this doesn't make it easier to use - users don't just include those
> > who write it. The antecedent language of these, Ada, from which this
> > syntax comes, was explicitly designed to be reader-friendly as opposed
On Thursday 23 June 2005 14:21, Josh Berkus wrote:
> Denis, all,
>
> > I got to thinking it¹d be kewl if PgAdmin3 supported an interactive
> > debugger for pl/pgsql. If anyone¹s interested in expertly tackling such
> > a community project, with some financial sponsorship from EDB, please
> > conta
Tom Lane <[EMAIL PROTECTED]> wrote:
> Unfortunately, I cannot believe these numbers --- the near equality of
> fsync off and fsync on means there is something very wrong with the
> measurements. What I suspect is that your ATA drives are doing write
> caching and thus the "fsyncs" are not really
Sounds great!
---
Alon Goldshuv wrote:
> This is a second iteration of a previous thread that didn't resolve few
> weeks ago. I made some more modifications to the code to make it compatible
> with the current COPY FROM code
> That might be explained by this 8.0.2/7.4.8 fix:
> This does bring up a question for Rod: have you installed a release
> including the above fix, and if so have you noticed the
> crash-after-SIGTERM problem since then?
We skipped 8.0.2 and went to 8.0.3 near the beginning of the month.
We we
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> I once noticed that there was something weird of Lock in win32 pg8.0.1. If
> you have many connections work concurrently intensively(say contrib/pgbench)
> and do fast shutdown in the middle, you will see an assertation failure
> here:
> if (lock->nRe
> The character-code conversion from EUC_JP to SJIS is executed by
> converting two stages. The first stage is conversion from EUC_JP to MIC.
> The next stage is conversion from MIC to SJIS. (Conversion from SJIS to
> EUC_JP is also similar.)
>
> It is not so efficient, because it is necessary to
Do we need to adjust /contrib/reindexdb? The README now is inaccurate,
and perhaps it should use the new syntax.
---
Tom Lane wrote:
> Log Message:
> ---
> Make REINDEX DATABASE do what one would expect, namely rein
On 2005-06-24, Tom Lane <[EMAIL PROTECTED]> wrote:
> Log Message:
> ---
> Fix rtree and contrib/rtree_gist search behavior for the 1-D box and
> polygon operators (<<, &<, >>, &>). Per ideas originally put forward
> by [EMAIL PROTECTED] and later rediscovered by moi. This patch just
> fix
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> Hmph. No obvious reason why that would be platform-dependent. Is it
> completely repeatable for you? (You might try the advice I just gave
> Dave Cramer: make distclean and rebuild to ensure you've got fully
> consistent bits ...)
>
I once noticed that
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> This won't work - it would miss the validators. Slightly more complex
> than I thought.
Well, there's always the brute-force solution:
regression=# explain analyze select * from pg_proc WHERE NOT proisagg AND
(pronamespace != (select oid from pg_name
Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> >> Curt Sampson <[EMAIL PROTECTED]> writes:
> >>> But is it really a problem? I somewhere got the impression that some
> >>> drives, on power failure, will be able to keep going for long enough to
> >>> write out the cache and park the he
On 2005-06-24, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Is there any reason for us to keep putting the language handler
>> functions in the public schema?
>
> I believe one of the issues there is that pg_dump doesn't dump functions
> that are in pg_catalo
I wrote:
Hmm. Could we not just add something this condition:
or pg_catalog.format_type(prorettype, NULL) != 'language_handler'
in pg_dump.c around line 2191?
This won't work - it would miss the validators. Slightly more complex
than I thought.
cheers
andrew
---
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Hmm. Could we not just add something this condition:
> or pg_catalog.format_type(prorettype, NULL) != 'language_handler'
> in pg_dump.c around line 2191?
You forgot about the validators, which are not so easily identified.
rega
Bruce Momjian writes:
> Tom Lane wrote:
>> The reason I question "automatic" is that you really want to test each
>> drive being used, if the system has more than one; but Postgres has no
>> idea what the actual hardware layout is, and so no good way to know what
>> needs to be tested.
> Some fol
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Is there any reason for us to keep putting the language handler
functions in the public schema?
I believe one of the issues there is that pg_dump doesn't dump functions
that are in pg_catalog. You could possibly fix it to m
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> Unfortunately, I cannot believe these numbers --- the near equality of
> >> fsync off and fsync on means there is something very wrong with the
> >> measurements. What I suspect is that your ATA
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Is there any reason for us to keep putting the language handler
> functions in the public schema?
I believe one of the issues there is that pg_dump doesn't dump functions
that are in pg_catalog. You could possibly fix it to make an exception
for funct
Hmmm ... just when you thought it was safe to go back in the water ...
I was only looking closely at the "box" case earlier today, assuming
that the polygon code was set up identically. Well, it isn't. In
particular it appears that the poly_overleft and poly_overright
definitions are different f
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2005-06-23, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I looked into the r-tree breakage discussed in this thread:
>> http://archives.postgresql.org/pgsql-general/2004-03/msg01135.php
> See also http://archives.postgresql.org/pgsql-bugs/2005-01/msg00
Is there any reason for us to keep putting the language handler
functions in the public schema? If they were put in, say, pg_catalog (as
I see Peter's pl/sh language does for its handler) then the public
schema could be dropped by people who want to do that with no ill
effect, AFAICS.
cheer
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Thu, Jun 23, 2005 at 05:59:25PM -0400, Tom Lane wrote:
>> Fixing the existing operators seems relatively straightforward; there will
>> need to be some extension to rtstrat.c to represent "NOT this operator"
>> as well as "this operator", but that's not
Tom Lane <[EMAIL PROTECTED]> writes:
> It would be a lot easier to sell that if it gave the right answers ;-)
Of course given that the real rtree index gives the wrong answers perhaps
moving rtree_gist into core (after fixing this) is just a bug fix :)
--
greg
---(end
On Thu, Jun 23, 2005 at 05:59:25PM -0400, Tom Lane wrote:
>
> Fixing the existing operators seems relatively straightforward; there will
> need to be some extension to rtstrat.c to represent "NOT this operator"
> as well as "this operator", but that's not hard. I plan to do this, and
> make the co
On 2005-06-23, Tom Lane <[EMAIL PROTECTED]> wrote:
> I looked into the r-tree breakage discussed in this thread:
> http://archives.postgresql.org/pgsql-general/2004-03/msg01135.php
See also http://archives.postgresql.org/pgsql-bugs/2005-01/msg00328.php
in which I made most of the same points.
Not
I looked into the r-tree breakage discussed in this thread:
http://archives.postgresql.org/pgsql-general/2004-03/msg01135.php
The executive summary: r-tree index opclasses contain four two-dimensional
operators, which behave correctly, and four one-dimensional operators
which do not. There is a b
Andrew Dunstan wrote:
It's not 100% repeatable, but I have seen it about 60% of the time
over 8 or 10 runs.
But now I can't reproduce it at all. :-(
cheers
andrew
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I just got this regression failure on Windows:
namespace.c::RelationIsVisible - line 319
Hmph. No obvious reason why that would be platform-dependent. Is it
completely repeatable for you? (You might try the
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Would testing in the WAL directory be sufficient? Or at least better
> than nothing? Of course we could test in the database directories as
> well, but you never know if stuff's been symlinked elsewhere... err, we
> can test for that, no?
>
> In any cas
Denis, all,
> I got to thinking it¹d be kewl if PgAdmin3 supported an interactive
> debugger for pl/pgsql. If anyone¹s interested in expertly tackling such a
> community project, with some financial sponsorship from EDB, please contact
> me privately.
Just FYI, EMS Hitech has a windows-only PL/p
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>> I just got this regression failure on Windows:
> namespace.c::RelationIsVisible - line 319
Hmph. No obvious reason why that would be platform-dependent. Is it
completely repeatable for you? (You might try the advice I just gave
Dave Cramer: make d
Alvaro,
I agree, a protocol seems to generally be the best option.
-Jonah
Alvaro Herrera wrote:
On Thu, Jun 23, 2005 at 01:40:18PM -0400, Matthew T. O'Connor wrote:
Tom Lane wrote:
Denis Lussier <[EMAIL PROTECTED]> writes:
I got to thinking it'd be kewl if PgAdmin3 suppor
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I just got this regression failure on Windows:
If it's repeatable, could you get a debugger stack trace from the
errfinish call? Or even just add "\set VERBOSITY verbose" to the
test script so we can tell which of the many
On Thu, Jun 23, 2005 at 01:40:18PM -0400, Matthew T. O'Connor wrote:
> Tom Lane wrote:
>
> >Denis Lussier <[EMAIL PROTECTED]> writes:
> >
> >
> >>I got to thinking it'd be kewl if PgAdmin3 supported an interactive
> >>debugger for pl/pgsql.
> >
> >That's been kicked around before, although I don'
Tom Lane wrote:
Denis Lussier <[EMAIL PROTECTED]> writes:
I got to thinking it'd be kewl if PgAdmin3 supported an interactive debugger
for pl/pgsql.
That's been kicked around before, although I don't think anyone wants to
tie it to pgAdmin specifically. Check the archives...
I d
> Has Kerb4 been marked as depricated in the docs at all? If
> not it might be best to just do that and then yank it later.
Yes, since 7.4.
http://www.postgresql.org/docs/8.0/static/auth-methods.html#KERBEROS-AUT
H
http://www.postgresql.org/docs/7.4/static/auth-methods.html#KERBEROS-AUT
H
"Ker
Jan Wieck <[EMAIL PROTECTED]> writes:
> I think pg_dump should add the check constraints in the same manner as
> it does triggers.
> Bruce, do we have a TODO item for this?
No, because that idea has been proposed and rejected before --- it adds
overhead (extra table scans) and reduces readability
On Wed, Jun 22, 2005 at 03:50:04PM -0400, Tom Lane wrote:
> The reason I question "automatic" is that you really want to test each
> drive being used, if the system has more than one; but Postgres has no
> idea what the actual hardware layout is, and so no good way to know what
> needs to be tested
On 6/22/2005 1:29 AM, Neil Conway wrote:
Tom Lane wrote:
The long-term point in my mind is that removing syntactical
redundancy always reduces the ability to detect errors or report
errors acccurately
Lexical scoping is unambiguous in a language like PL/PgSQL. Since it is
simple to determine
On Wed, Jun 22, 2005 at 04:39:15PM -0400, Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > Yeah. But it has been declared dead by the Kerberos folks
> > (http://www.faqs.org/faqs/kerberos-faq/general/section-7.html. And this
> > document is from 2000, an dit was declared already
Euler Taveira de Oliveira <[EMAIL PROTECTED]> writes:
>> Anyone want to get to work on replacing reindexdb or userlock?
>>
> I'll submit a replacement for reindexdb ASAP.
OK. Note I committed the previously discussed REINDEX DATABASE/SYSTEM
changes yesterday, so you might be able to use that.
Hi Tom,
> Anyone want to get to work on replacing reindexdb or userlock?
>
I'll submit a replacement for reindexdb ASAP.
Euler Taveira de Oliveira
euler[at]yahoo_com_br
___
Yahoo! Acesso Grátis - Internet
Added pgsql-hackers
Added Bruce Momjian
On 6/23/2005 12:19 PM, Michael Fuhr wrote:
The question I have is how exactly you manage to get the trigger fired
when restoring the dump. By default, the dump created by pg_dump will
create the table, fill in the data and create the trigger(s) only afte
On Thu, Jun 23, 2005 at 16:13:24 +0800,
laser <[EMAIL PROTECTED]> wrote:
>
> This thread make me to think about the question:
> could this "feature" be used in select count(*) type
> query that force it to use index?
count(*) can already be helped by indexes, but probably not the way you think.
On Thu, Jun 23, 2005 at 11:08:55AM -0400, Andrew Dunstan wrote:
> I just got this regression failure on Windows:
Maybe it has to do with being unable to drop the relcache file?
> == pgsql.2220/src/test/regress/regression.diffs
> ===
> *** ./expected/prepared_xact
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I just got this regression failure on Windows:
If it's repeatable, could you get a debugger stack trace from the
errfinish call? Or even just add "\set VERBOSITY verbose" to the
test script so we can tell which of the many instances of that
string this
That worked, thanks
Interestingly enough I specified --with-pgport=5433 and it used 5432
instead ?
./configure --prefix=/Users/davec/projects/postgres/pghead/pgsql --
with-pg-port=5433 --enable-debug
This configure line worked on linux
Dave
On 23-Jun-05, at 10:47 AM, Tom Lane wrote:
Dav
Dave Cramer <[EMAIL PROTECTED]> writes:
> Interestingly enough I specified --with-pgport=5433 and it used 5432
> instead ?
Maybe you have PGPORT=5432 in your environment?
regards, tom lane
---(end of broadcast)---
TIP 3: i
Denis Lussier <[EMAIL PROTECTED]> writes:
> I got to thinking it'd be kewl if PgAdmin3 supported an interactive debugger
> for pl/pgsql.
That's been kicked around before, although I don't think anyone wants to
tie it to pgAdmin specifically. Check the archives...
regards,
I just got this regression failure on Windows:
== pgsql.2220/src/test/regress/regression.diffs
===
*** ./expected/prepared_xacts.out Thu Jun 23 10:20:28 2005
--- ./results/prepared_xacts.outThu Jun 23 10:45:06 2005
***
*** 179,189
-- Commi
Tom Lane wrote:
Richard Huxton writes:
laser wrote:
Aggregate (cost=19638.60..19638.60 rows=1 width=0) (actual
time=1567.317..1567.318 rows=1 loops=1)
-> Seq Scan on partial_idx_t (cost=1.00..18327.88
rows=524288 width=0) (actual time=0.046..906.747 rows=524288 loops=1)
To
Dave Cramer <[EMAIL PROTECTED]> writes:
> I am getting the following error
> initializing pg_depend ... FATAL: plan requires more slots than are
> available
make distclean ... rebuild ... if it's still there after that, let us
know.
regards, tom lane
--
Same code works fine on linux
looking at execTuple this error should not occur
Dave
On 23-Jun-05, at 8:42 AM, Dave Cramer wrote:
I am getting the following error
initializing pg_depend ... FATAL: plan requires more slots than
are available
This is a laptop, and may be a result of not ha
Richard Huxton writes:
> laser wrote:
>> Aggregate (cost=13933.39..13933.39 rows=1 width=0) (actual
>> time=1901.761..1901.762 rows=1 loops=1)
>> -> Index Scan using partial_idx on partial_idx_t (cost=0.00..12622.93
>> rows=524183 width=0) (actual time=0.130..1230.634 rows=524288 loops=1)
>> Index
Title: PL/pgSQL Debugger Support
Hi All,
Sorry if this isn’t the right forum for this question... But, I noticed that Alvaro wrote
“... we don't have good debugging support in pl/pgsql ...”
I got to thinking it’d be kewl if PgAdmin3 supported an interactive debugger for pl/pgsql. If anyone
Same code works fine on linux
Looking at execTuples this error should never happen
Dave
On 23-Jun-05, at 8:42 AM, Dave Cramer wrote:
I am getting the following error
initializing pg_depend ... FATAL: plan requires more slots than
are available
This is a laptop, and may be a result of not
"John Hansen" <[EMAIL PROTECTED]> writes:
>> I'll look at problem after GiST concurrency. Fixing
>> rtree_gist is bug a fix, not a new feature, so I'm not
>> limited by 1 July.
> Wont fixing rtree(_gist) require initdb, since the behaviour of the
> operators will change?
Possibly, but we never
Oleg Bartunov writes:
> something is broken in HEAD. I recall it worked in STABLE, here is what I have
No, actually it is broken in 8.0 too. The difference is that 8.0
defaults to not using an indexscan for this query. In 8.0 I see:
regression=# set enable_seqscan TO 1;
SET
regression=# explai
I am getting the following error
initializing pg_depend ... FATAL: plan requires more slots than are
available
This is a laptop, and may be a result of not having enough shared mem
available ?
Dave
---(end of broadcast)---
TIP 1: subscribe
Alfranio Correia Junior wrote:
I think it is ok now.
However, I corrected the indentation manually.
I could not run some of the tools, namely the "entab".
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/varargs.h:4:2: #error
"GCC no longer implements ."
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3
laser wrote:
> This thread make me to think about the question:
> could this "feature" be used in select count(*) type
> query that force it to use index?
No. Because of issues with concurrent updates to the table. See archives
for discussion.
> I make a little test, but found a strange phenoment
"Tom Lane" <[EMAIL PROTECTED]> writes
>
>
> together with some kind of IPC to waken backends once xlog was flushed
> past the point they needed. (Designing that is the hard part.)
>
I think we could use ProcSendSignal()/ProcWaitForSignal() mechanism to cope
with the problem, because they won't l
This thread make me to think about the question:
could this "feature" be used in select count(*) type
query that force it to use index?
I make a little test, but found a strange phenoment,
created a simple table:
create table partial_idx_t(id serial, f1 integer, f2 text);
then insert many rows
Hmm,
something is broken in HEAD. I recall it worked in STABLE, here is what I have
Welcome to psql 8.0.3, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolo
68 matches
Mail list logo
