On Wed, Apr 11, 2001 at 10:44:59PM -0700, Ian Lance Taylor wrote:
Mark Butler [EMAIL PROTECTED] writes:
...
The advantages of using a hand written recursive descent parser lie in
1) ease of implementing grammar changes
2) ease of debugging
3) ability to handle unusual cases
4)
Thank you. Is an "exception condition" necessarily an error, or
is a warning also an exception condition ?
A warning/notice is called a "completion condition".
Because other db's only raise a warning. Of course we don't want to
copy that behavior if they are not conformant. See
Thomas Lockhart wrote:
The age() functions *preserve* the qualitative fields year and month. So
you see the difference in results:
Why take away age()? I usually use it to check against INTERVALs? See:
village= select age(date '1999-05-17', date '1957-06-13') '40
years'::interval;
?column?
Someone said Oracle raises an error.
Informix seems to be the only other db that truncates silently.
Raises a warning instead of error. Would need to check Sybase and DB2, but ...
Yes, good. Do we want this in 7.1.0 ? Seems, yes :-(
No, pretty sure this will not fly for the 7.1.x cycle,
Thomas Lockhart writes:
The age() functions *preserve* the qualitative fields year and month. So
you see the difference in results:
lockhart=# select age('today', '1957-06-13');
-
43 years 9 mons 28 days
lockhart=# select timestamp 'today' - timestamp
ISTM that this is more a result of
a) timestamp subtraction not implemented per spec
Maybe. But it is implemented consistantly, and is more functional and
capable than the brain-damaged SQL9x spec (c.f. Date and Darwen) asks.
b) date substraction not implemented at all (it does date -
Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's
patch should be applied?
Cheers,
Patrick
(just checked, it isn't in today's cvs)
On Thu, Mar 22, 2001 at 10:27:44PM +0200, Marko Kreen wrote:
On Thu, Mar 22, 2001 at 07:58:04PM +, Patrick Welche wrote:
On Fri,
Thomas Lockhart writes:
b) date substraction not implemented at all (it does date - integer)
No, and changing what it *does* do has ramifications.
Okay, I see there's 'date - date' after all. But 'date - date' should
still return some kind of time interval, not an integer. Of course
Thomas Lockhart writes:
Typical date/time arithmetic resolves to an absolute time or interval.
In those cases, *qualitative* quantities such as years and months are
resolved to a specific absolute interval at the time of calculation.
The age() functions *preserve* the qualitative fields
Zeugswetter Andreas SB writes:
Yes, good. Do we want this in 7.1.0 ? Seems, yes :-(
No way. I'm just giving some food for thought while development is slow.
In any case there seems to be support for the proposed feature. I'm just
waiting for someone to complain that he relies on the
Mark Butler writes:
I was trying to make a minor change today to the gram.y file to make
PostgreSQL recognize "DOUBLE" as a data type the way DB2 does. I ran into
reduce / reduce conflicts using both of the methods I tried.
See attached patch.
--
Peter Eisentraut [EMAIL PROTECTED]
set nomail
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Thanks. I didn't realize the need to move the DOUBLE token from the TokenId to
the ColId production. Will this patch be integrated into the head branch?
- Mark Butler
Peter Eisentraut wrote:
Mark Butler writes:
I was trying to make a minor change today to the gram.y file to make
Zeugswetter Andreas SB wrote:
Yes, good. Do we want this in 7.1.0 ? Seems, yes :-(
I agree this change is very good idea, but 7.2 is probably a better target.
- Mark Butler
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
In the FAQ..
http://www.postgresql.org/docs/faq-english.html#4.7
Good luck!
-Mitch
Software development :
You can have it cheap, fast or working. Choose two.
- Original Message -
From: "Mitesh Shah" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 12, 2001 6:10 PM
Thanks!
One follow up question. In the example given, it says there are 36
bytes for each row header and 4 bytes for each pointer to a tuple. I'm
not sure where these numbers (36 and 4) are coming from. Are they
standard for *every* table? If my table has more than just two
integers, for
Mitesh Shah writes:
One follow up question. In the example given, it says there are 36
bytes for each row header and 4 bytes for each pointer to a tuple. I'm
not sure where these numbers (36 and 4) are coming from. Are they
standard for *every* table? If my table has more than just two
Mark Butler writes:
Thanks. I didn't realize the need to move the DOUBLE token from the TokenId to
the ColId production. Will this patch be integrated into the head branch?
Not sure. It's not a standard type, but at least two other RDBMS have it
and the name does make sense. Any
I was looking at how hard it would be to support altering column types and it
seems to me that it would be trivial to support changing nullability,
increasing the maximum length of the VARCHAR data type and increasing the
precision or scale of the DECIMAL / NUMERIC data type.
Oracle allows you
Bruce Momjian wrote:
That's a tough call. We already have some duplicate type symbols, but
this is not a standard SQL type. I would see if we can get others to
say it is a good idea.
But the DOUBLE keyword is already reserved by ANSI for use in the "DOUBLE
PRECISION" type, so a "DOUBLE"
I noticed the storage format for the numeric type is rather inefficient:
typedef struct NumericData
{
int32 varlen; /* Variable size*/
int16 n_weight; /* Weight of 1st digit */
uint16 n_rscale; /* Result scale */
uint16
Mark Butler wrote:
I was looking at how hard it would be to support altering column types and it
seems to me that it would be trivial to support changing nullability,
Yes. The problem is how to formulate 'DROP CONSTRAINT' feature.
increasing the maximum length of the VARCHAR data type and
22 matches
Mail list logo
