Fwd: [HACKERS] int type problem in 7.3

Ok, I checked this again. Up until 7.2, it was possible to compare an empty string to a number, and it worked:: e.g.: select * from mytable where int4id='' worked fine, but delivered no result. This is exactly what Oracle did here, a comparison like this does not work: SQL> select * from re_ein

[HACKERS] int type problem in 7.3

It seems queries like: select ... from table where id='' (an empty string) do not work anymore, it worked up to 7.2. This will make migration to 7.3 quite difficult for some application, especially for oracle applications. Would'nt it be better to evaluate such expressions to false. Regards,

[HACKERS] some more minor incompatibilties 7.2 <-> 7.3

I noticed some other minor differences between 7.2 and 7.3: * 7.2: select now() + '1 minute'::timespan => works * 7.2: select now() + '1 minute'::reltime => works * 7.3: select now() + '1 minute'::timespan => does not work (Type "timespan" does not exist) * 7.3 select now() + '1 minute'::reltime

Re: [HACKERS] 7.2.3 patching done

Hello! On Tue, 1 Oct 2002, Bruce Momjian wrote: > In some releases, it is possible, in others we add/remove files and it > isn't possible. I think because it isn't always possible we normally > don't do it. I think it's enough to do diffs for minor release (i.e. 7.2.2->7.2.3, 7.3.0->7.3.1 and

[HACKERS] New PostgreSQL Website : advocacy.postgresql.org

Hi all, Over the last few weeks we've put together a new "Advocacy and Marketing" website for PostgreSQL: http://advocacy.postgresql.org It's now ready for public release. It has the first few case studies, lists the major advantages to PostgreSQL, and provides a place you can point your CIO,

Re: [HACKERS] pg_dump and large files - is this a problem?

At 11:20 AM 1/10/2002 -0400, Bruce Momjian wrote: BSD/OS has 64-bit off_t's so it does support large files. Is there something I can test? Not really since it saves only the first 32 bits of the 64 bit positions it will do no worse than a version that supports 32 bits only. It might even do s

Re: [HACKERS] pg_dump and large files - is this a problem?

At 09:59 AM 1/10/2002 -0400, Tom Lane wrote: >If there is a problem, seems like we'd better fix it. Perhaps there >needs to be something in the header to tell the reader the sizeof >off_t. Yes, and do the peripheral stuff to support old archives etc. We also need to be careful about the places

Re: [HACKERS] 7.2.3 patching done

Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Peter Eisentraut wrote: > >> Adding or removing files isn't the problem (see -N option). Binary files > >> are the problem. > > > Do we change any binary files in minor releases, or even major ones? > > But the source distribution

Re: [HACKERS] table lock and record lock

On Tue, 1 Oct 2002, John Liu wrote: > what's the default lock in pgsql? > > if I issued insert(copy)/or update processed > on the same table but on different records > the same time, how those processes will > affect each other? postgresql does not do "locking" in the sense of how most databas

[HACKERS] Purpose of rscale/dscale in NUMERIC?

What is the reason for maintaining separate rscale and dscale values in numeric variables? I am finding that this arrangement leads to some odd results, for example this: regression=# select (exp(ln(2.0)) - 2.0); ?column? - -0. (1 row) regression=# sel

Re: [HACKERS] table lock and record lock

On Tue, Oct 01, 2002 at 03:30:38PM -0500, John Liu wrote: > what's the default lock in pgsql? > > if I issued insert(copy)/or update processed > on the same table but on different records > the same time, how those processes will > affect each other? You might want to check out the docs at

[HACKERS] table lock and record lock

what's the default lock in pgsql? if I issued insert(copy)/or update processed on the same table but on different records the same time, how those processes will affect each other? thanks. johnl ---(end of broadcast)--- TIP 3: if posting/readin

Re: [HACKERS] 7.2.3 patching done

Bruce Momjian <[EMAIL PROTECTED]> writes: > Peter Eisentraut wrote: >> Adding or removing files isn't the problem (see -N option). Binary files >> are the problem. > Do we change any binary files in minor releases, or even major ones? But the source distribution hasn't *got* any binary files.

Re: [HACKERS] 7.2.3 patching done

Peter Eisentraut wrote: > Bruce Momjian writes: > > > > BTW, is it possible to have just patch against previous version (to reduce > > > traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz? > > > > In some releases, it is possible, in others we add/remove files and it > > isn't possible. I

Re: [HACKERS] psqlODBC *nix Makefile (new 7.3 open item?)

Dave Page writes: > > > majority of you!) knock up a makefile so the driver will build > > > standalone on *nix systems please? There should be no > > dependencies on > > > any of the rest of the code - certainly there isn't for the Win32 > > > build. > > > > I'm working something out. I'll send

Re: [HACKERS] 7.2.3 patching done

Bruce Momjian writes: > > BTW, is it possible to have just patch against previous version (to reduce > > traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz? > > In some releases, it is possible, in others we add/remove files and it > isn't possible. I think because it isn't always possibl

Re: [HACKERS] pg_dump and large files - is this a problem?

Tom Lane writes: > Yes, it does --- the implication is that the custom format, at least, > can't support dumps > 4Gb. What exactly is pg_dump writing off_t's > into files for; maybe there's not really a problem? That's kind of what I was wondering, too. Not that it's an excuse, but I think tha

Re: [HACKERS] [COMMITTERS] pgsql/contrib/rserv ApplySnapshot.in CleanLog.

Alexey V. Borzov writes: > Agh! I finally read up on module loading > http://developer.postgresql.org/docs/postgres/xfunc-c.html#XFUNC-C-DYNLOAD > and now I seem to understand. You see, the problem with the current > Makefile is as follows: it substitutes '$libdir' into both .sql and > pe

Re: [HACKERS] Postgresql likes Tuesday...

If it's of any use the following link gives some info on different schemes and details on an ISO week numbering standard. http://www.merlyn.demon.co.uk/weekinfo.htm#WkNo Best Regards, Tim Knowles ---(end of broadcast)--- TIP 1: subscribe and uns

Re: [HACKERS] pg_dump and large files - is this a problem?

Tom Lane wrote: > Philip Warner <[EMAIL PROTECTED]> writes: > > Is it my imagination, or is there a problem with the way pg_dump uses off_t > > etc. My understanding is that off_t may be 64 bits on systems with 32 bit > > ints. But it looks like pg_dump writes them as 4 byte values in all cases.

Re: [HACKERS] 7.2.3 patching done

Yury Bokhoncovich wrote: > Hello! > > BTW, is it possible to have just patch against previous version (to reduce > traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz? In some releases, it is possible, in others we add/remove files and it isn't possible. I think because it isn't always p

Re: [HACKERS] floor function in 7.3b2

"Mario Weilguni" <[EMAIL PROTECTED]> writes: > I noticed that some of my queries don't work anymore because they're using > the floor function: > e.g.: select type, floor(date_part('epoch', dataend)) as ts from > last_modified > Why is floor not working anymore? Mph. Seems we have floor(numeric)

[HACKERS] floor function in 7.3b2

I noticed that some of my queries don't work anymore because they're using the floor function: e.g.: select type, floor(date_part('epoch', dataend)) as ts from last_modified Why is floor not working anymore? I guess I can use round too, but I don't want to modify semantics. Regards, Mari

Re: [HACKERS] pg_dump and large files - is this a problem?

Philip Warner <[EMAIL PROTECTED]> writes: > Is it my imagination, or is there a problem with the way pg_dump uses off_t > etc. My understanding is that off_t may be 64 bits on systems with 32 bit > ints. But it looks like pg_dump writes them as 4 byte values in all cases. > It also reads them a

Re: [HACKERS] Postgresql likes Tuesday...

Karel Zak <[EMAIL PROTECTED]> writes: > What think about it our Toms? > ... > In the Oracle it's same (means WW vs. IW vs. D) If it works the same as Oracle then I'm happy with it; that's what it's supposed to do. The real point here seems to be that EXTRACT(week) corresponds to to_date's IW

[HACKERS] pg_dump and large files - is this a problem?

Is it my imagination, or is there a problem with the way pg_dump uses off_t etc. My understanding is that off_t may be 64 bits on systems with 32 bit ints. But it looks like pg_dump writes them as 4 byte values in all cases. It also reads them as 4 byte values. Does this seem like a problem to

Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)

> > Attached is a patch to fix the mb linking problems on AIX. As a nice side effect > > it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so > > (all shlibs that are not postmaster loadable modules). > > Can you explain the method behind your patch? Have you tried -bnogc

Re: [HACKERS] 7.2.3 patching done

Hello! BTW, is it possible to have just patch against previous version (to reduce traffic and CPU)? I.e. something like 7.2.2-7.2.3.diff.gz? -- WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group. Phone: +7 (3832) 106228, ext.140, E-mail: [EMAIL PROTECTED] Unix is like a wigwa

Re: [HACKERS] Postgresql likes Tuesday...

On Mon, Sep 30, 2002 at 05:37:47PM -0400, Rod Taylor wrote: > select to_char( >to_date( > CAST(extract(week from CURRENT_TIMESTAMP) as text) > || CAST(extract(year from CURRENT_TIMESTAMP) as text) > , 'WW') >, 'FMDay, D'); > > to_char > > Tuesday, 3 >