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 .
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
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
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
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)--
to ignore ...
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
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
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
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
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
> 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
> > 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
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
> -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:
> > >
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 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
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
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
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:
> > > 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
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/
> -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
"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
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
--
#
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 <[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
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
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,
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
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,
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
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
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
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
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
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
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
> 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
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
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
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
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
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,
> > 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
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
> >
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
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
47 matches
Mail list logo
