Tom Lane wrote:
>
> I just finished running the parallel regress tests with inval.c rigged
> to flush the relcache and syscache at every available opportunity,
> that is anytime we could recognize a shared-cache-inval message from
> another backend (see diff below). This setup gives a whole new u
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> In the meantime, I haven't quite figured out how to
> start decoupling my various projects from my long-standing
> [EMAIL PROTECTED] address,
I'm not even trying ... I don't work for SSS anymore, but I'll be
[EMAIL PROTECTED] for the foreseeable futur
> PS: "fourpalms.org" ?
Yup. I finally got DSL at home, and in the 4 months between ordering and
installation thelockharts.org plus some other candidates (including the
names of every animal in the household, and we have lots!) had vanished.
I'll explain the significance of the name over beers t
> >> I suspect we're stuck on that for AS. However, TYPE is actually allowed
> >> as a ColId, via the 'generic' production, so in reality it's not
> >> reserved.
> > I think this generic production might be a mistake.
> It looks fairly weird to me too. Seems to me that we should get rid of
> tok
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I'd assume that it should be using fractional seconds only, just like
> timestamp_part() does. Any reason not to change it for 7.1?
Agreed.
> btw, what should 'microseconds' return? It suffers from the problems
> mentioned already, plus leaves the "m
> Any thought?
Hmm. It is not consistantly implemented :(
timestamp_part() uses just the fractional part of the seconds to
calculate milliseconds. But interval_part() uses both fractional and
integer parts to figure the result, and that is the routine which ends
up being used for the time value.
I just finished running the parallel regress tests with inval.c rigged
to flush the relcache and syscache at every available opportunity,
that is anytime we could recognize a shared-cache-inval message from
another backend (see diff below). This setup gives a whole new universe
of meaning to the
It seems we do not have the standard SQL function "bit_length()"?
--
Tatsuo Ishii
Hi to all.
Im in search for a tool or way to migrate data from a Cobol file to SQL
and then To PostgreSQL or direct.
Im trying to create a Datawarehouse with PostgreSQL and Zope to create
interactive reports from an Old Cobol System. (The Client dont want to
migrate to PSQL all of his system)
Matthew <[EMAIL PROTECTED]> writes:
> I posted a note to the hackers list about this very issue last week. It was
> never responded to. I am prepared to do the work and submit a patch, but I
> wanted some input on how best to do it. We had a problem with a backup
> script silently failing when
At 19:14 4/01/01 -0600, Matthew wrote:
>I posted a note to the hackers list about this very issue last week. It was
>never responded to. I am prepared to do the work and submit a patch, but I
>wanted some input on how best to do it. We had a problem with a backup
>script silently failing when t
I posted a note to the hackers list about this very issue last week. It was
never responded to. I am prepared to do the work and submit a patch, but I
wanted some input on how best to do it. We had a problem with a backup
script silently failing when the disk was full. I guess I will get start
I am writing an article of PostgreSQL 7.1 and have some questions.
I can get the millisecond part of a timestamp data using date_part.
test=# SELECT date_part('millisecond','2001/1/15 12:04:05.1234'::TIMESTAMP);
date_part
---
123.4
(1 row)
However if I apply the function to a tim
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I suspect we're stuck on that for AS. However, TYPE is actually allowed
>> as a ColId, via the 'generic' production, so in reality it's not
>> reserved.
> I think this generic production might be a mistake.
It looks fairly weird
Tom Lane writes:
> > (For the interested, the only other completely reserved tokens are TYPE
> > and AS.)
>
> I suspect we're stuck on that for AS. However, TYPE is actually allowed
> as a ColId, via the 'generic' production, so in reality it's not
> reserved.
I think this generic production mi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I have noticed that AND and TRAILING could be made ColLabel's without
> further changes. Currently they are completely reserved. (This is
> especially odd given that OR is a ColLabel.) Would that be okay to
> change?
If you don't get shift/reduce
I've attached a bit of c code to do md5 checksums on text. There's
nothing too original here, this was mostly just ripped from rfc1321,
with some driver code added for PostgreSQL. Also a Makefile and a test
schema.
Sorry if this isn't the right place to post such a thing. I had just
noticed a
I have noticed that AND and TRAILING could be made ColLabel's without
further changes. Currently they are completely reserved. (This is
especially odd given that OR is a ColLabel.) Would that be okay to
change?
(For the interested, the only other completely reserved tokens are TYPE
and AS.)
-
[EMAIL PROTECTED] writes:
> But the tcl build fails and I think it is because configure creates an
> erroneous mkMakefile.tcldefs.sh unless USE_TCL is defined.
> Just a note for something that may need to be repaired so tcl can be added
> after an initial postgres build w/o having to re configur
Ok... I found bug, it was me ;)))
In some strange moment I add this tables to template1 instead of
test. Maybe I must go sleep more ;)).
regards
Robert
> I dont know if I do something wrong or it is normal for PG :)
> So
>
> template1=# select version();
>versi
I dont know if I do something wrong or it is normal for PG :)
So
template1=# select version();
version
-
PostgreSQL 7.0.3 on i486-pc-linux-gnu, compiled by gcc egcs-2.91.66
(1 row)
And now:
templa
I agree with all your conclusions. I thought many of the items on the
TODO list looked like things you had addressed. TODO list updated.
Thanks.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Would people please check the TODO list in pgsql/doc/TODO or on our web
> > site, and let me know if
Seems these are all properly listed in the HISTORY file for the 7.1
release.
>
> Don't know whether this belongs on the TODO, but it probably needs to go
> somewhere in a 'New Features' section (at least the first two items):
>
> pg_dump:
>
>
> - Support BLOBs in pg_dump (pjw)
> - new
23 matches
Mail list logo
