Mark Butler <[EMAIL PROTECTED]> writes:
> I noticed the storage format for the numeric type is rather inefficient:
> ...
> A zero value uses two bytes total in Oracle, where in the current version of
> PostgreSQL it uses ten bytes.
Yawn ... given row overhead, alignment padding, etc, this is not
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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 ha
Mark Butler <[EMAIL PROTECTED]> writes:
> Surely if we have an write exclusive table lock we can rewrite tuples
> in place rather than creating new versions with its corresponding 2x
> space requirement.
Nyet. Consider transaction rollback.
regards, tom lane
---
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 a
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 n
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"
[EMAIL PROTECTED] (Nathan Myers) writes:
> We have noticed here also that object (e.g. table) names get truncated
> in some places and not others. If you create a table with a long name,
> PG truncates the name and creates a table with the shorter name; but
> if you refer to the table by the s
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
> 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.
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 tw
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 exam
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 comments?
Is there a Web site or some info somewhere that tells you how to
estimate the size of your database.
I know what my schema is and how many records will be in each table (but
non have been inserted yet). How can I project how much disk space I
will need for the database?
Thanks!
Mitesh
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
Sub
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
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
>
set nomail
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
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]
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 existin
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
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
ch
-- Forwarded Message --
Subject: Re: Yacc / Bison difficulties
Date: Thu, 12 Apr 2001 13:01:40 +0200
From: Robert Schrem <[EMAIL PROTECTED]>
To: Mark Butler <[EMAIL PROTECTED]>
On Thursday 12 April 2001 03:38, you wrote:
> I was trying to make a minor change today to the gram
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
> 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 - inte
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 '195
> > 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 cyc
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;
?colu
> > 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
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 case
29 matches
Mail list logo
