On Wed, Oct 03, 2001 at 05:40:08PM +, Thomas Lockhart wrote:
> ? A local copy of the *repository*, not a checked out version of the
> tree. CVSup is too cool for words ;)
Oops, should read mail more carefully. :-)
> Building CVSup from scratch is not trivial, since it requires the
> installa
> Is this an expected behavior? I could not see why t1 and t2 are
> showing different time resolutions...
Even stranger, this only happens on the first call to CURRENT_TIMESTAMP
after starting a backend (example below), and stays that way if I just
do "select current_timestamp". Something must no
Is this an expected behavior? I could not see why t1 and t2 are
showing different time resolutions...
test=# create table t3(t1 timestamp(2), t2 timestamp(2) default current_timestamp);
CREATE
test=# insert into t3 values(current_timestamp);
INSERT 16566 1
test=# select * from t3;
t1
...
> Sure, I said *after* we fail to find an exact match. But the "freebie"
> match is for a function name that matches a type name and is
> binary-compatible with the source type. That's not a weak constraint.
> ISTM that interpretation should take priority over interpretations that
> involve
> Problem: the external representation of time and timestamp are
> less precise than the internal representation.
Fixed (as of yesterday) in the upcoming release.
- Thomas
---(end of broadcast)---
TIP 2: you can ge
> > Ok. I ran the modified test (now the iteration is reduced to 10 in
> > liketest()). As you can see, there's huge difference. MB seems up to
> > ~8 times slower:-< There seems some problems existing in the
> > implementation. Considering REGEX is not so slow, maybe we should
> > employ the
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> When I recompiled with LOCK_DEBUG and trace_lwlocks = true, it *works*
> (and saw lots of lock debugging messages, of course). However if I
> turn trace_lwlocks to off, the backend stucks again.
Ugh ... ye classic Heisenbug ...
> Is there anything I can
> I think that we were supposed to go beta a month ago, and so this is
> no time to start adding new features to this release. Let's plan to
> make this happen (one way or the other) in 7.3, instead.
Agreed.
--
Tatsuo Ishii
---(end of broadcast)--
> If you have no better way of determining what's going on, it might help
> to recompile with LOCK_DEBUG defined, then enable trace_lwlocks in
> postgresql.conf (better turn on debug_print_query, log_timestamp, and
> log_pid too). This will generate rather voluminous log output, perhaps
> enough
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> What do you think?
I think that we were supposed to go beta a month ago, and so this is
no time to start adding new features to this release. Let's plan to
make this happen (one way or the other) in 7.3, instead.
regards, tom la
> What's your feeling now about the original question: whether to enable
> multibyte by default now, or not? I'm still thinking that Peter's
> counsel is the wisest: plan to do it in 7.3, not today. But this fix
> seems to eliminate the only hard reason we have not to do it today ...
If SQL99's
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> Is it possible for Postgresql to bind to one IP address?
See 'virtual_host' GUC parameter.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Hi people,
Is it possible for Postgresql to bind to one IP address?
I'm trying to run multiple postgresql installations on one server.
The unix socket could be named accordingly:
Postgresql config bound to a particular port and all IPs.
.s.PGSQL.
Postgresql config bound to a particular port
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> To accomplish this, I moved MatchText etc. to a separate file and now
> like.c includes it *twice* (similar technique used in regexec()). This
> makes like.o a little bit larger, but I believe this is worth for the
> optimization.
That sounds great.
Wha
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> Perhaps it'd be a better idea for the option of a freebie conversion
>> to be checked earlier, say immediately after we discover there is no
>> exact match for the function name and input type. Thomas, what do you
>> think?
> We *really* need that c
> Ok. I ran the modified test (now the iteration is reduced to 10 in
> liketest()). As you can see, there's huge difference. MB seems up to
> ~8 times slower:-< There seems some problems existing in the
> implementation. Considering REGEX is not so slow, maybe we should
> employ the same desig
Problem: the external representation of time and timestamp are
less precise than the internal representation.
We are using postgresql 7.1.3
The timestamp and time types support resolving microseconds (6 places beyond the
decimal), however the output routines round the value to only 2
...
> Perhaps it'd be a better idea for the option of a freebie conversion
> to be checked earlier, say immediately after we discover there is no
> exact match for the function name and input type. Thomas, what do you
> think?
We *really* need that catalog lookup first. Otherwise, we will never
On Mié 03 Oct 2001 16:43, you wrote:
> On Mar 02 Oct 2001 21:59, you wrote:
> > In 7.1.X and earlier the INSERT rules are executed _before_ the INSERT.
> > This is changed to _after_ in 7.2.
>
> This would mean...??? I haven´t had much trouble until now, so I can´t
> understand why one of the 4 in
> Tom Lane writes:
>
> > In the meantime, we still have the question of whether to enable
> > multibyte in the default configuration.
>
> This would make more sense if all of multibyte, locale, and NLS became
> defaults in one release. I haven't quite sold people in the second item
> yet, altho
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Looking at the explain verbose output, it looks like it may be doing a
> conversion to name because it looks like there isn't a text(varchar),
> but there's a text(name) and a name(varchar). My guess is there's no
> text(varchar) because they're conside
> Thanks for your reply.
> Yes, CEST equals to CETDST
> please add CEST as a synonym to existing timezone code (if it is possible)
Done in my sources; will be committed soon.
- Thomas
---(end of broadcast)---
TIP 5: Have you
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> COMMENT ON AGGREGATE my_aggregate double precision IS 'Computes
> sample variance';
>
> works but looks strange syntax. Should we fix the program or docs?
>> I vote for fixing the program.
> If we fix this, we should also change DROP AGGREGATE, w
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> In the meantime, we still have the question of whether to enable
>> multibyte in the default configuration.
> Perhaps we could make it a release goal for 7.3
Yeah, that's probably the best way to proceed... it's awfully late
in t
Tom Lane writes:
> In the meantime, we still have the question of whether to enable
> multibyte in the default configuration.
This would make more sense if all of multibyte, locale, and NLS became
defaults in one release. I haven't quite sold people in the second item
yet, although I have a des
On Mar 02 Oct 2001 21:59, you wrote:
> In 7.1.X and earlier the INSERT rules are executed _before_ the INSERT.
> This is changed to _after_ in 7.2.
This would mean...??? I haven´t had much trouble until now, so I can´t
understand why one of the 4 inserts of the rule didn´t get through.
Is there
> #select text(v) from t;
>
> text
> -
> 0123456789a0123456789b012345678
> (1 row)
>
> Truncation occurs.
Looking at the explain verbose output, it looks
like it may be doing a conversion to name because
it looks like there isn't a t
I can confirm this problem exists in current sources. Quite strange.
> #create table t (v varchar);
> #insert into t values ('0123456789a0123456789b0123456789c0123456789d');
>
> #select v from t;
>
> v
>
#create table t (v varchar);
#insert into t values ('0123456789a0123456789b0123456789c0123456789d');
#select v from t;
v
--
0123456789a0123456789b0123456789c0123456789d
(1 row)
So far, so good.
#select te
> Bruce,
>
> I notice HISTORY in CVS doesn't mentioned any development we did
> with GiST. Should we write some info ? Major things we did:
>
> 1. Null-safe interface to GiST
> 2. Support of multi-key GiST indices
I had generic GIST improvements. Updated to:
Allow GIST to handle NULLs and mul
Bruce,
I notice HISTORY in CVS doesn't mentioned any development we did
with GiST. Should we write some info ? Major things we did:
1. Null-safe interface to GiST
2. Support of multi-key GiST indices
TODO
Adding concurrency for GiST
Regards,
Oleg
__
> BTW, would you object to my removing the macros
> IS_BUILTIN_TYPE(), IS_HIGHER_TYPE(), IS_HIGHEST_TYPE()
> from parse_coerce.h? They are used nowhere and are not
> being maintained --- eg, they don't seem to know about
> TIMESTAMPTZ.
OK. I had already stripped out some "#if NOT_USED" code but
...
> So the real issue appears to be that subsecond resolution isn't
> propagating into time and timetz at all.
Ah. Of course it isn't, because I (probably) didn't change
DecodeTimeOnly() to use the microsecond resolution version of the
transaction time. Will look at it.
BTW, would you object to my removing the macros
IS_BUILTIN_TYPE(), IS_HIGHER_TYPE(), IS_HIGHEST_TYPE()
from parse_coerce.h? They are used nowhere and are not
being maintained --- eg, they don't seem to know about
TIMESTAMPTZ.
regards, tom lane
---
...
> It's fairly disconcerting that f2 and f3 don't agree, wouldn't you say?
:) I'll look at it.
- Thomas
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
> Is it a bug or CEST timezone is not supported anymore ?
> I can't import my 7.1.2 database to current development version of
> postgresql
afaik "CEST" was never supported by PostgreSQL. Can you please confirm
that this is the same as "CETDST" (Central European Time, Daylight
Savings Time) or, p
...
> > I use CVSup to keep a local copy of the cvs repository on my laptop, so
> > I have a *full* development environment when I'm traveling or otherwise
> > off line. I'd have a very hard time working without it...
> Yes, that was my original thinking too. But CVS could do the same.
? A local
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Added to TODO:
>
> > * Use wide characters to evaluate regular expressions, for performance
> > (Tatsuo)
>
> Regexes are fine; it's LIKE that's slow.
Oops, thanks. Changed to:
* Use wide characters to evaluate LIKE, for performance (Tatsuo)
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
> * Use wide characters to evaluate regular expressions, for performance
> (Tatsuo)
Regexes are fine; it's LIKE that's slow.
regards, tom lane
---(end of broadcast)--
Further experimentation:
regression=# create table foo3 (f1 date default current_date,
regression(# f2 time(3) default current_time,
regression(# f3 timestamp(3) default current_timestamp);
CREATE
regression=# insert into foo3 default values;
(multiple times)
regression=# select * from foo3;
With current CVS, I did
regression=# create table foo (f1 date default current_date,
regression(# f2 time default current_time,
regression(# f3 timestamp default current_timestamp);
CREATE
regression=# \d foo
Table "foo"
Column | Type |
Hi,
I am currently struggling to write a "serialize"-like function
that would dump a row of a table into a string-like object in a way that
would allow me to reconstruct the original row (or its individual
elements) from this object.
The tentative plan I have is something like t
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > ... There seems some problems existing in the
> > implementation. Considering REGEX is not so slow, maybe we should
> > employ the same design as REGEX. i.e. using wide charcters, not
> > multibyte streams...
>
> Seems like a good thing to put on the
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > ... There seems some problems existing in the
> > implementation. Considering REGEX is not so slow, maybe we should
> > employ the same design as REGEX. i.e. using wide charcters, not
> > multibyte streams...
>
> Seems like a good thing to put on th
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> ... There seems some problems existing in the
> implementation. Considering REGEX is not so slow, maybe we should
> employ the same design as REGEX. i.e. using wide charcters, not
> multibyte streams...
Seems like a good thing to put on the to-do list.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
> You are right. Please, apply attached patch or copy result/btree_gist.out
> expected/btree_gist.out
>
>
> Tom Lane wrot
Is it a bug or CEST timezone is not supported anymore ?
I can't import my 7.1.2 database to current development version of
postgresql
lis=# create table test (ts timestamp);
CREATE
lis=# insert into test values ('23.05.2000 09:06:59.00 CEST');
ERROR: Bad timestamp external representation '23.05
At 06:36 PM 10/2/2001, Hiroshi Inoue wrote:
>The cause is that the stored function uses a common
>snapshot throughout the function execution. As I've
>complained many times, the current implementaion is
>far from intuition and this case seems to show that
>it isn't proper at all either.
Bravo! Th
Peter Eisentraut writes:
> However, it seems to me that COPY ignoring duplicates can easily be
> done by preprocessing the input file.
Or by post-processing, like (error checking cut):
void import_shots(char *impfile, int lineshoot_id)
{
char tab_name[128];
char tab_temp[128];
frig_fi
> I don't think your search string is sufficient for a test.
> With 'aaa' it actually knows that it only needs to look at the
> first three characters of a. Imho you need to try something
> like liketest(a,'%aaa%').
Ok. I ran the modified test (now the iteration is reduced to 10 in
liketes
On Wed, Oct 03, 2001 at 02:27:20AM +, Thomas Lockhart wrote:
> It may be that the static tarballs for RedHat will work for you (they
> work for me on Mandrake).
Maybe. But then I could compile the sources myself.
> I use CVSup to keep a local copy of the cvs repository on my laptop, so
> I h
You are right. Please, apply attached patch or copy result/btree_gist.out
expected/btree_gist.out
Tom Lane wrote:
> In current CVS I see a failure in the btree_gist regression test.
> It kinda looks like the test data was changed without updating the
> expected results, but would you verify th
> - shell script ---
> for i in 32 64 128 256 512 1024 2048 4096 8192
> do
> psql -c "explain analyze select liketest(a,'aaa') from
> (select substring('very_long_text' from 0 for $i) as a) as a" test
> done
> - shell script ---
I don't th
> You are attacking here two things:
>
> a) schemas, which should be done in 7.3,
Is imho something different alltogether. (I know we have two opposed
views here)
> thus multiple databases on same host would be unnecessary.
I disagree :-)
>
> b) connections to remote host' databases, whic
> Maybe something like this: declare a plpgsql function that takes two
> text parameters and has a body like
>
> for (i = 0 to a million)
> boolvar := $1 like $2;
>
> Then call it with strings of different lengths and see how the runtime
> varies. You need to apply the LIKE
55 matches
Mail list logo
