On E, 2005-08-29 at 09:50 +0400, Oleg Bartunov wrote:
> Hi there,
>
> I'm a bit surprised how bad could be plan for unused table.
> I had to cancel second query :)
...
> tp=# explain analyze select tp_rewrite_substitute(query,
> 'select p.name_tsquery, p.name_alias_tsquery from place p')
> from
Hi there,
I'm a bit surprised how bad could be plan for unused table.
I had to cancel second query :)
tp=# explain analyze select tp_rewrite_substitute(query,
'select p.name_tsquery, p.name_alias_tsquery from place p')
from to_tsquery('new&york&hotel') as query;
y;
David Fetter <[EMAIL PROTECTED]> writes:
> On a slightly related note, I've noticed that psql isn't backward
> compatible.
We have never expected psql's \d commands to work against older server
versions, and two months after feature freeze isn't the time to start
making that happen.
Folks,
I've noticed that \df doesn't do quite what it might when a function
is created with named input parameters. Please find enclosed a patch
against CVS TIP that does this better.
On a slightly related note, I've noticed that psql isn't backward
compatible. I know that it's *very* late to b
* optional interface which sends a row typeoid along with each row in a result
set
Oh, and 'select rowid, * from table' which returns special rowid column
that just incrementally numbers each row.
Chris
---(end of broadcast)---
TIP 6: explain
Yeah, I think it's a timing thing on when the fix was committed and when
Beta1 was pulled.
It will be in the next beta/release based on the commit I saw.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail
Patch applied. Autoconf run. Thanks.
---
Dave Page wrote:
>
>
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > Sent: 28 August 2005 22:56
> > To: Dave Page
> > Cc: pgsql-hackers@postgr
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 28 August 2005 22:56
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Win32 Thread safetyness
>
>
> Well, actually I tried to run configure --enable-thread-safety on a
> MinGW platf
I have the following conferences scheduled:
Sept 7-10, Sri Lanka
Sept 17, New York City
October 17-20, Amsterdam
Information is on the PostgreSQL Events list and my home page. I also
have a possible Armenia trip for early October, and Mexico for
mid-November.
--
Bruce
Tom Lane wrote:
> Bruce Momjian writes:
> > Magnus Hagander wrote:
> >>> Also, there doesn't seem to be a good way for users to know
> >>> if libpq or ecpg was compiled to be thread-safe.
> >>
> >> Right. A runtime function for this might be a good thing? Like "bool
> >> PQisThreadSafe()" or suc
Dave Page wrote:
> > So, we might be able to get away without this on Win32, or perhaps the
> > pthread_self().p is a valid unique identifier for Win32 threads and
> > pthreads.
>
> Right.
>
> > How is this pthread_self() call working on Win32 now? Is pthreads a
> > requirement for libpq threadi
I'm currently testing pgAdmin support for slony, on pgsql CVS HEAD, and
encounter strange problems from time to time.
After dropping and recreating the slony schema, all changes committed
and all backends in state, I'm getting
"relation with OID xxx does not exist" when I'm trying to add a path.
Bruce Momjian writes:
> Magnus Hagander wrote:
>>> Also, there doesn't seem to be a good way for users to know
>>> if libpq or ecpg was compiled to be thread-safe.
>>
>> Right. A runtime function for this might be a good thing? Like "bool
>> PQisThreadSafe()" or such?
> Yes, and a flag to ecpg.
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 28 August 2005 18:19
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Win32 Thread safetyness
>
>
> I poked around this one. The SSL locking documentation is at:
>
> http://www.
Magnus Hagander wrote:
> > The basic issue with SSL is that it wants some unique
> > identifier for threads. They really should have defined the
> > function to take pthread_t rather than unsigned long because
> > pthreads doesn't really give us a useful way to get an
>
> They absolutely shou
> The basic issue with SSL is that it wants some unique
> identifier for threads. They really should have defined the
> function to take pthread_t rather than unsigned long because
> pthreads doesn't really give us a useful way to get an
They absolutely should not have done that. That would'v
Awhile back I wrote:
> Hmm, I don't see that symptom, but I do see some strange stuff building
> PG CVS tip on a fully-up-to-date (10.4.2) OS X machine.
> ...
> Second, at exit from an interactive psql session,
> regression=# \q
> could not save history to file "/Users/tgl/.psql_history": Invalid
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>During testing of 8.1 I found that using pg_dumpall (-g) against a live
>>8.0 install that has at least one GROUP defined results in the following
>>warning while it creates the CREATE ROLE statements in the dump:
>>row number
I poked around this one. The SSL locking documentation is at:
http://www.die.net/doc/linux/man/man3/crypto_set_id_callback.3.html
The description isn't clear. When they talk about locking_function()
and id_function(void), they are talking about arguments to the SSL
functions listed above, no
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> During testing of 8.1 I found that using pg_dumpall (-g) against a live
> 8.0 install that has at least one GROUP defined results in the following
> warning while it creates the CREATE ROLE statements in the dump:
> row number 0 is out of range 0.
[EMAIL PROTECTED] writes:
> Our friendly psql complains that pg_shadow is a view:
> psql::11: ERROR: cannot delete from a view
> HINT: You need an unconditional ON DELETE DO INSTEAD rule.
Yeah, this is on the open-items list; the DELETE FROM is broken (and
was always a pretty bogus appro
Hi!
During testing of 8.1 I found that using pg_dumpall (-g) against a live
8.0 install that has at least one GROUP defined results in the following
warning while it creates the CREATE ROLE statements in the dump:
row number 0 is out of range 0..-1
To reproduce the problem it is enough to init
AIUI, the issue is statements like:
# select numeric(6,3) '5.6';
Bison can't look far enough ahead to determine whether the numeric is a
type or a function. However, the desired grammer itself is not
ambgiuous, it's just that Bison is not smart enough to make it work. It
works now only because we
Hi,
It seems the timestamp.c patch to getg around the SCO optimizer bug did'nt
get in beta1
Is it normal?
Regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-8
24 matches
Mail list logo
