Hi all,
I'm hacking on PalmOS handhelds to implements libpq
called "libpq for PalmOS".
This library provides many compatible libpq functions
to manipulate PostgreSQL server from PalmOS devices
through TCP/IP connection.
Implementation is almost done, but some works are left
to release.
For exa
Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> ! Because of the limited utility of hash indexes, a B-tree index
> ! should generally be preferred over a hash index. We do not have
> ! sufficient evidence that hash indexes are actually faster than
> ! B-trees even for = c
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> > ! Because of the limited utility of hash indexes, a B-tree index
> > ! should generally be preferred over a hash index. We do not have
> > ! sufficient evidence that hash indexes are actually faster than
> >
> > a) The client-side programmer has to be responsible for parsing the
> > returned string, which could cause problems if the output format of the
> > ADT is changed, and
> You seem to be proposing that we instead expose the internal storage
> format of the ADT, which seems to me to be much more
On Thu, 20 Jun 2002, Bruce Momjian wrote:
> OK, I have finally decided that our archive searching stinks. I have
> emails in my mailbox that don't appear in the archives.
>
> Our main site, http://archives.postgresql.org/ doesn't archive the
> 'patches' list. (It isn't listed on the main site,
This is all great news. Thanks.
---
Marc G. Fournier wrote:
> On Thu, 20 Jun 2002, Bruce Momjian wrote:
>
> > OK, I have finally decided that our archive searching stinks. I have
> > emails in my mailbox that don't appea
Curt Sampson <[EMAIL PROTECTED]> writes:
> And now you know which parts of your page got written, and which
> parts didn't.
Yes ... and what do you *do* about it?
regards, tom lane
---(end of broadcast)---
TIP 3: if posting
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, which part of is "demonstrably false"? I think the old "should
> generally be preferred" is too vague. No one has come up with a case
> where hash has shown to be faster, and a lot of cases where it is slower.
The only thing I recall being lots wo
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> That is one possibility, but I think the proposal is to expose the
> *support* for the data types to client-side apps.
Ah, I see --- more or less make all of utils/adt/ available to be
linked into clients.
> That is a Good Idea in principle. In pract
> Ah, I see --- more or less make all of utils/adt/ available to be
> linked into clients.
> > That is a Good Idea in principle. In practice, ...
> Yeah, it'd be a huge amount of work. For starters, all that code
> relies on the backend environment for error handling and memory
> management...
I
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, which part of is "demonstrably false"? I think the old "should
> > generally be preferred" is too vague. No one has come up with a case
> > where hash has shown to be faster, and a lot of cases where it is slower.
>
> The only
On Fri, 2002-06-21 at 17:07, Marc G. Fournier wrote:
> > Can we find out why the email/news gateway drops messages?
>
> Email->News gateways aren't the best to start with, since they rely on far
> too many variables ... main one coming to mind is if the news server is
> down for any length o
On Wed, Jun 19, 2002 at 10:14:32AM -0400, Tom Lane wrote:
> I agree it's not pleasant to be blocked like this. Is there any way we
> can persuade the bison guys to be a little more urgent about releasing a
> fix? (If 1.49 is just an internal beta version, maybe a back-patch to
> their last relea
For some reason a view with a select distinct, an order and an exception
by will cause pg_dump to output a double order by -- one for each select
which of course is bad SQL.
PSQL
rbt_t=# create view test as select distinct relname, reltuples, relnatts
from pg_class where relkind = 't' excep
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I remember three problems: build time, index size, and concurrency
> problems. I was wondering about the equal key case myself, and assumed
> hash may be a win there, but with the concurrency problems, is that even
> possible?
Sure. Many-equal-keys a
damn, I wish ppl would bring stuff like this up earlier :( I've just gone
through the configs, and think the problem(s) are fixed with this ... :(
On 21 Jun 2002, Alessio Bragadini wrote:
> On Fri, 2002-06-21 at 17:07, Marc G. Fournier wrote:
>
> > > Can we find out why the email/news gate
Hi,
I am about to add code to postgresql that would allow IDENT
authentification with DES encryption (as seen in the pidentd package
included with Redhat - not sure if same encryption is used by other
ident daemons). The code would allow for two types of IDENT
authentification:
ident - this is
Any idea if alter table drop column and background vacuum will be
implemented by 7.3?
It's really critical for large applications that must run 24/7.
Stephen
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister co
Hi all,
I'm hacking on PalmOS handhelds to implements libpq
called "libpq for PalmOS".
This library provides many compatible libpq functions
to manipulate PostgreSQL server from PalmOS devices
through TCP/IP connection.
Implementation is almost done, but some works are left
to release.
For exa
Julian Mehnle wrote:
> [...] I made a patch.
>
> ==8<==snip==
> [word-wrapped patch]
> ==snip==>8==
Doh!
I swear I told my news reader not to word-wrap exactly this message,
but it wrapped it anyway.
Hi all!
Recently I tried to use the new 7.02.0001 Win32 ODBC driver in the new
(beta) Unicode mode in conjunction with MS Access 2000 and a "UNICODE"
encoded database stored in a PostgreSQL 7.2.1 database running on a
Linux system.
I noticed that when the "LF<->CRLF Conversion" option is *enable
Rod Taylor <[EMAIL PROTECTED]> writes:
> For some reason a view with a select distinct, an order and an exception
> by will cause pg_dump to output a double order by -- one for each select
> which of course is bad SQL.
This is fixed in current sources and REL7_2 branch.
r
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I remember three problems: build time, index size, and concurrency
> > problems. I was wondering about the equal key case myself, and assumed
> > hash may be a win there, but with the concurrency problems, is that even
> > possible?
Rod Taylor wrote:
>
> For some reason a view with a select distinct, an order and an exception
> by will cause pg_dump to output a double order by -- one for each select
> which of course is bad SQL.
I think views should not have ORDER BY clauses at all in the first
place.
Jan
--
#
"David M. Kaplan" <[EMAIL PROTECTED]> writes:
> I am about to add code to postgresql that would allow IDENT
> authentification with DES encryption (as seen in the pidentd package
> included with Redhat - not sure if same encryption is used by other
> ident daemons).
What's the point, exactly?
Fo
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 21, 2002 6:32 AM
> To: Tom Lane
> Cc: Neil Conway; [EMAIL PROTECTED]; Dann Corbit;
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] What is wrong with hashed index usage?
>
>
> Tom Lane wrote:
> > Bruc
bash-2.05a$ make install > /dev/null
In file included from tupdesc.c:22:
../../../../src/include/funcapi.h:69: syntax error before `uint'
Dropping the u works fine.
FreeBSD fury.inquent.com 4.5-RELEASE FreeBSD 4.5-RELEASE #1: Mon Feb 4
13:30:57 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/
Dann Corbit wrote:
> > > This change strikes me as a step backwards. The existing
> > wording tells
> > > the truth; the proposed revision removes the facts in favor
> > of a blanket
> > > assertion that is demonstrably false.
> >
> > OK, which part of is "demonstrably false"? I think the old
On Fri, 2002-06-21 at 11:51, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> >
> > > How about an elog(NOTICE) for hash use?
> >
> > I don't think that's appropriate.
>
> I was thinking of this during CREATE INDEX ... hash:
>
> NOTICE: Hash ind
Dann Corbit wrote:
> > I was thinking of this during CREATE INDEX ... hash:
> >
> > NOTICE: Hash index use is discouraged. See the CREATE INDEX
> > reference page for more information.
> >
> > Does anyone else like/dislike that?
>
> I think it might be OK temporarily, to show that the
Larry Rosenman wrote:
> On Fri, 2002-06-21 at 11:51, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> >
> > >
> > > > How about an elog(NOTICE) for hash use?
> > >
> > > I don't think that's appropriate.
> >
> > I was thinking of this during CREATE
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 21, 2002 9:52 AM
> To: Tom Lane
> Cc: Neil Conway; [EMAIL PROTECTED]; Dann Corbit;
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] What is wrong with hashed index usage?
>
>
> Tom Lane wrote:
> > Bruc
On Fri, 2002-06-21 at 15:12, Bruce Momjian wrote:
> Larry Rosenman wrote:
> > On Fri, 2002-06-21 at 11:51, Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> > >
> > > >
> > > > > How about an elog(NOTICE) for hash use?
> > > >
> > > > I don't th
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 21, 2002 1:31 PM
> To: Dann Corbit
> Cc: Tom Lane; Neil Conway; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] What is wrong with hashed index usage?
>
>
> Dann Corbit wrote:
> > >
During the discussion of bools and hash index and partial indexes and
index growth and everything else, I tried to make a partial index on a
bool field and got the error that "data type bool has no default operator
for class hash..."
So, can I cast something to make this work, or is it possibl
> > I've got patches for the CREATE CAST/DROP CAST feature (just a
> > rearrangement of our existing function declaration syntax). The SQL99
> > form assumes that an existing function will be used for the cast
> > definition, so I've extended the syntax to allow that and to have an
> > alternate f
> So, is you vote for or against the elog(NOTICE)?
OK, if we are still voting, then I'll mention that I generally dislike
the idea of notices of this kind. And would not like this notice in
particular. So would vote no with both hands ;)
I'm pretty sure that we have a consensus policy (hmm, at l
On the other hand, I like hints on how to do things better ;)
David
Thomas Lockhart wrote:
>>So, is you vote for or against the elog(NOTICE)?
>>
>>
>
>OK, if we are still voting, then I'll mention that I generally dislike
>the idea of notices of this kind. And would not like this notice in
I've gone ahead and committed patches for CREATE CAST/DROP CAST, as well
as for a few other SQL99 clauses in other statements. Details below...
- Thomas
Implement SQL99 CREATE CAST and DROP CAST statements.
Also implement alternative forms to expose the PostgreSQL CREATE
FUN
Which is whay you RTFM ;)
--On Friday, June 21, 2002 10:10 PM -0400 David Ford
<[EMAIL PROTECTED]> wrote:
> On the other hand, I like hints on how to do things better ;)
>
> David
>
> Thomas Lockhart wrote:
>
>>> So, is you vote for or against the elog(NOTICE)?
>>>
>>>
>>
>> OK, if we are still
ignore this one ...
---(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 get through to the mailing list cleanly
to ignore ...
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Okay, just did a series of upgrades to the server to hopefully speed up
delivery a bit ... 6minutes more reasonable? let's see if it keeps up,
mind you ...
On Fri, 21 Jun 2002, Marc G. Fournier wrote:
>
> ignore this one ...
>
>
> ---(end of broadcast)--
On Fri, 2002-06-21 at 22:06, Marc G. Fournier wrote:
>
> Okay, just did a series of upgrades to the server to hopefully speed up
> delivery a bit ... 6minutes more reasonable? let's see if it keeps up,
> mind you ...
Thanks, Marc. I assume this is in response to my note about the
multi-hour del
Thomas Lockhart wrote:
> > So, is you vote for or against the elog(NOTICE)?
>
> OK, if we are still voting, then I'll mention that I generally dislike
> the idea of notices of this kind. And would not like this notice in
> particular. So would vote no with both hands ;)
>
> I'm pretty sure that
OK, fixed. uint changed to uint32.
---
Rod Taylor wrote:
> bash-2.05a$ make install > /dev/null
> In file included from tupdesc.c:22:
> ../../../../src/include/funcapi.h:69: syntax error before `uint'
>
>
> Dropping the
yup, as well as Francisco's ...
On 21 Jun 2002, Larry Rosenman wrote:
> On Fri, 2002-06-21 at 22:06, Marc G. Fournier wrote:
> >
> > Okay, just did a series of upgrades to the server to hopefully speed up
> > delivery a bit ... 6minutes more reasonable? let's see if it keeps up,
> > mind you .
47 matches
Mail list logo
