"Ross J. Reedstrom" wrote:
>
> On Fri, Feb 25, 2000 at 06:25:12PM -0600, [EMAIL PROTECTED] wrote:
> > oops, it's "timestamp" now (just name change).
> > BTW, I remember datetime is in sql92. "timestamp" is also in sql92? why
> > "timestamp" is better than "datetime" ? sql99(96) ?
>
> Nope, DATE
On Fri, Feb 25, 2000 at 06:25:12PM -0600, [EMAIL PROTECTED] wrote:
> oops, it's "timestamp" now (just name change).
> BTW, I remember datetime is in sql92. "timestamp" is also in sql92? why
> "timestamp" is better than "datetime" ? sql99(96) ?
Nope, DATETIME is not an SQL92 type, it's a class of
oops, it's "timestamp" now (just name change).
BTW, I remember datetime is in sql92. "timestamp" is also in sql92? why
"timestamp" is better than "datetime" ? sql99(96) ?
thanks!
On Fri, 25 Feb 2000, Barnes wrote:
> Nay, my friend, no mistake. Rather, I have you and Kaiq to thank for
> setting
Nay, my friend, no mistake. Rather, I have you and Kaiq to thank for
setting me straight, and I fully intend to follow your advice. What you say
makes sense, and I'll go with it.
I will use the datetime as well.
Thank you.
David Barnes
-Original Message-
From: [EMAIL PROTECTED]
[mail
On Fri, 25 Feb 2000, Karl DeBisschop wrote:
>
> > From: <[EMAIL PROTECTED]>
> > On Fri, 25 Feb 2000, Karl DeBisschop wrote:
> >
> > >
> > > >>To summarize, I stated that the following does not work with
> > > >>postgresql:
> > > >>
> > > >>> $dbh->{AutoCommit} = 0;
> > > >>> $
> From: "Keith G. Murphy" <[EMAIL PROTECTED]>
>
> Karl DeBisschop wrote:
> >
> > To summarize, I stated that the following does not work with
> > postgresql:
> >
> > > $dbh->{AutoCommit} = 0;
> > > $dbh->do("CREATE TABLE tmp (a int unique,b int)");
> > > while (<>){
> > >
> From: <[EMAIL PROTECTED]>
> On Fri, 25 Feb 2000, Karl DeBisschop wrote:
>
> >
> > >>To summarize, I stated that the following does not work with
> > >>postgresql:
> > >>
> > >>> $dbh->{AutoCommit} = 0;
> > >>> $dbh->do("CREATE TABLE tmp (a int unique,b int)");
> > >>>
Karl DeBisschop wrote:
>
> To summarize, I stated that the following does not work with
> postgresql:
>
> > $dbh->{AutoCommit} = 0;
> > $dbh->do("CREATE TABLE tmp (a int unique,b int)");
> > while (<>){
> > if (/([0-9]+) ([0-9]+)/) {
> > $rtv = $dbh->do("INSERT INTO tmp VALUES ($1,$2
On Fri, 25 Feb 2000, Karl DeBisschop wrote:
>
> >>To summarize, I stated that the following does not work with
> >>postgresql:
> >>
> >>> $dbh->{AutoCommit} = 0;
> >>> $dbh->do("CREATE TABLE tmp (a int unique,b int)");
> >>> $rtv = $dbh->do("INSERT INTO tmp VALUES ($1,$2)");
> >>>
>>To summarize, I stated that the following does not work with
>>postgresql:
>>
>>> $dbh->{AutoCommit} = 0;
>>> $dbh->do("CREATE TABLE tmp (a int unique,b int)");
>>> $rtv = $dbh->do("INSERT INTO tmp VALUES ($1,$2)");
>>> if ($rtv) {$dbh->do("UPDATE tmp SET b=$2 where a=$1")};
>>>
I didn't say you could write a good application.
David Boerwinkle
-Original Message-
From: Ed Loehr <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>; Barnes <[EMAIL PROTECTED]>;
[EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, Febr
[EMAIL PROTECTED] wrote:
>
> The advantage of (3) is that it would be extremely easy to write an
> application around. However, the inflexibility of it makes my stomach
> tighten. I agree with kaiq, I think you're making a mistake.
Hmmm. What would a SQL query look like in (3) that finds all
The advantage of (3) is that it would be extremely easy to write an
application around. However, the inflexibility of it makes my stomach
tighten. I agree with kaiq, I think you're making a mistake.
David Boerwinkle
-Original Message-
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: Barn
On Fri, 25 Feb 2000, Patrick Welche wrote:
> On Fri, Feb 25, 2000 at 09:56:59AM -0600, [EMAIL PROTECTED] wrote:
> >
> > do not use date, use datetime. why? it's sql92 standard (another
> > good reason: M$sql only has datetime :-). A lot of useful functions
> > only apply to datetime, not date.
On Fri, Feb 25, 2000 at 09:56:59AM -0600, [EMAIL PROTECTED] wrote:
>
> do not use date, use datetime. why? it's sql92 standard (another
> good reason: M$sql only has datetime :-). A lot of useful functions
> only apply to datetime, not date.
On a side note: if I have a date d and a time t column
3) is weird. it looks like a typical mistatke that use the data
as the schema. It is not flexible and waste of disk (ya, I know
it cheap. but it you waste too much!). And, more importantly,
you gain nothing. the "correct" table is already so simply!
do not use date, use datetime. why? it's sql92
First, let me start off by thanking you two for the design ideas. You've
been very helpful, as have Ed and Omid who focused more on laying the
groundwork for approaching the problem.
Maybe I'm overcomplicating things. You both seem to be suggesting a table
something like:
1) date | doctor |
Hello friends,
many months ago I starting messing with stored procedures with PostgreSQL,
and at the time, I found out that I could only return "one" value when I
used a stored procedure.
I was wondering if this has changed or has/will/could be changed/implemented
with PostgreSQL 7.0?
It would
At 11:08 AM 25-02-2000 +0100, Wim Ceulemans wrote:
>Unless you want to store for example your contacts in an RDBMS on your
>personal computer, instead of using MS-Outlook that uses an inefficient
>storage format and no integrity checks.
>
>You would in this case use the database server always just
Dustin Sallings wrote:
>
> On Thu, 24 Feb 2000, root wrote:
>
> # > I'm writing this email to you from a notebook. Running Linux. And Postgres.
> # > :-) So, it's already being done (Notebooks aren't the issue here, I believe
> # > it's an issue of OS choices).
> #
> # There're still some Windo
20 matches
Mail list logo
