will this function/index problem be fixed in 7.x ?
ircbot=> explain select * from logins where dttime = NOW();
NOTICE: QUERY PLAN:
Seq Scan on logins (cost=33530.89 rows=71043 width=52)
EXPLAIN
ircbot=> explain select * from logins where dttime = NOW()::datetime;
NOTICE: QUERY PLAN:
Seq Sca
On Sun, 26 Dec 1999, Marc G. Fournier wrote:
> On Sat, 25 Dec 1999, Clark C. Evans wrote:
> > Plug-in Oracle 7 compatibility.
>
> I know we have (and have for awhile) a good deal of Oracle
> compatibility...what do you mean by 'Plug-In Oracle 7 compatibility'?
Plug in Oracle compatibility would
Mike Mascari wrote:
>
> Thomas Reinke wrote:
>
> > 1) Up front, I'll state that we use 6.3, so a number of
> >the technical glitches may have been solved since...
>
> 6.3 is unbelievably old. Perhaps you weren't getting responses since most
> people don't use versions of PostgreSQL that o
Chris Carbaugh wrote:
> What is the best way to import a table from Microsoft Access 2000?
>
> I was able to export to a text file from access, but this was only the
> data. Can I export/import the table definition as well?
>
> I have been using pgaccess to administer my DB. It seems I can't te
Thomas Reinke wrote:
> 1) Up front, I'll state that we use 6.3, so a number of
>the technical glitches may have been solved since...
6.3 is unbelievably old. Perhaps you weren't getting responses since most
people don't use versions of PostgreSQL that old? I know I tend not to respond
to pos
What is the best way to import a table from Microsoft Access 2000?
I was able to export to a text file from access, but this was only the
data. Can I export/import the table definition as well?
I have been using pgaccess to administer my DB. It seems I can't tell
it to import a comma delimite
> I believe we are adding Oracle compatibility as possible. We
are
> working on write-ahead log, long tuples, foreign keys, and
outer
> joins.
> Anything else?
Yes, PL/SQL compatibility would be nice. ;-)
Bye,
Oliver
#--{ [EMAIL PROTECTED] }
Oliver Fischer, Glei
At 10:27 PM 12/25/99, Bruce Momjian wrote:
>[snip]
> > Plug-in Oracle 7 compatibility.
>
>I believe we are adding Oracle compatibility as possible. We are
>working on write-ahead log, long tuples, foreign keys, and outer joins.
>Anything else?
Replication would be nice, or some other form of clu
>
> > once again. The *perception* remains, however, that pgsql still
> > leaves a bit to be desired in the areas of reliability and
> > maintainability. This needs to be remedied. Like I said, progress
> > has been mad, but it appears pgsql isn't quite out of the woods yet.
>
> I keep hearin
"Marc G. Fournier" wrote:
> On Sun, 26 Dec 1999, Ed Loehr wrote:
>
> > Bruce Momjian wrote:
> >
> > > We don't have roll-forward logging until 7.1, and require vacuum
> > > regularly. Other than that, I don't know of any major issues.
> > > Reliability has always been of primary importance. We
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi,
>
> > > The 3 greatest technical/engineering challenges: 1) system
> > > reliability & recoverability, 2) system reliability & recoverability,
> > > and 3) system reliability and recoverability.
> >
> > And we don't have a problem in
> Howdy
>
> A question, if you still have some code in the source that
> originated at Berkeley how do you change the license?
>
> Do you breakout new code from old code and have a different
> license for old vs. new code?
Just add it to the top. If someone wants it without oure
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> > I believe we are adding Oracle compatibility as possible. We are
> > working on write-ahead log, long tuples, foreign keys, and outer joins.
> > Anything else?
>
> Yes, earlier in the year I was trying to migrate from Pervasive SQL to
>
On Sat, 25 Dec 1999, Bruce Momjian wrote:
> >
> >
> > On Sat, 25 Dec 1999, Bruce Momjian wrote:
> > > My big question is, what new challenges will we face as
> > > we become more popular?
> >
> > Plug-in Oracle 7 compatibility.
>
> I believe we are adding Oracle compatibility as possible. W
Howdy
A question, if you still have some code in the source that
originated at Berkeley how do you change the license?
Do you breakout new code from old code and have a different
license for old vs. new code?
> I'm against any change in license, except for the upcoming exten
Peter Berghold wrote:
> Thanks! I was looking in the wrong spot! Did a search of CPAN with
> the key DBI::* and didn't see DBD::Pg. DOH!
Right. I also couldn't find DBD::Pg if I search that key.
> Building it right now.
Good luck,
Kevin.
Thanks! I was looking in the wrong spot! Did a search of CPAN with
the key DBI::* and didn't see DBD::Pg. DOH!
Building it right now.
>> Original Message <<
On 12/26/99, 4:42:10 AM, Kevin Lo <[EMAIL PROTECTED]> wrote regarding
Re: [GENERAL] DBI::Pg for Perl?
Peter Berghold wrote:
> Hi Folks,
> Does anyone out there know of a DBI driver for Postgres for Perl? I
> searched CPAN and didn't see one. Maybe I'm looking in the wrong
> spot...
It's at :
http://www.perl.com/CPAN-local/modules/by-module/DBD/DBD-Pg-0.93.tar.gz
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> I believe we are adding Oracle compatibility as possible. We are
> working on write-ahead log, long tuples, foreign keys, and outer joins.
> Anything else?
Yes, earlier in the year I was trying to migrate from Pervasive SQL to
posgtres and
came to a screaming halt when it wouldn't do a large v
19 matches
Mail list logo
