> -- If I have interpreted SQL92 correctly UNKNOWN IS TRUE should return
> FALSE, and UNKNOWN IS NOT TRUE is equivalent to NOT (UNKNOWN IS TRUE) ==>
> TRUE. Is this correct?
No, I do not think it is valid to say "should return true|false"
I think they should return UNKNOWN. Only when it comes to
I wrote:
> Is anyone else seeing this with current CVS, or is it my own breakage?
Ah, the problem is RelationGetRelationName didn't know about the
new temprel naming convention.
I quick-hacked rel.h to fix this, but we need a better solution.
I don't much like having rel.h include temprel.h ---
Is anyone else seeing this with current CVS, or is it my own breakage?
*** ./expected/alter_table.out Wed May 30 12:38:38 2001
--- ./results/alter_table.out Tue Jun 19 00:45:22 2001
***
*** 340,347
ALTER TABLE FKTABLE ADD FOREIGN KEY(ftest1) references pktable(ptest1);
NOT
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am confused what you are suggesting here.
*** src/backend/utils/adt/format_type.c.origWed May 23 18:10:19 2001
--- src/backend/utils/adt/format_type.c Mon Jun 18 21:41:53 2001
***
*** 178,184
break;
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Very few people know the standards stuff so it seems we should just call
> it timestamp and do the best we can. Basically by mentioning "with
> timezone" we are making the standards people happy but confusing our
> users.
I don't believe we're making a
On Mon, Jun 11, 2001 at 12:21:56PM -0400, Robert E. Bruccoleri wrote:
> Dear Tom,
> >
> >
> > [EMAIL PROTECTED] (Robert E. Bruccoleri) writes:
> > > BTW, given the high level of support that you provide to the PostgreSQL
> > > community, it's very accurate to state that support for PostgreSQL
>
Perfect, thank you ... i knew I was overlooking something obvious ... the
query just flies now ...
On Mon, 18 Jun 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> >> Try adding ... AND n.nid = 15748 ... to the WHERE.
>
> > n.nid is the note id ... nl.id is the contact id
"Joe Conway" <[EMAIL PROTECTED]> writes:
> I also noticed that in PostgreSQL I can do the following (both before and
> after this patch):
> select f2 is null from foo;
> whereas in both Oracle and MSSQL it causes a syntax error. Any thoughts on
> this?
I dug into this further and discovered t
The Hermit Hacker <[EMAIL PROTECTED]> writes:
>> Try adding ... AND n.nid = 15748 ... to the WHERE.
> n.nid is the note id ... nl.id is the contact id ...
Ooops, I misread "n.nid = nl.nid" as "n.nid = nl.id". Sorry for the
bogus advice.
Try rephrasing as
FROM (note_links nl JOIN notes n ON (
On 18 Jun 2001 17:00:41 -, you wrote:
>
>Hello All.
>
>How can i limit how much of cpu the postmaster can use?
Maybe your host OS can limit the resource usage of the userid that
postmaster runs under?
--
__
"Nothing is as subjective as reality
Sergio Bruder <[EMAIL PROTECTED]> writes:
> [bruder@mapi2 postgresql-7.1.2]$ file
>src/bin/pgaccess/doc/html/tutorial/copyright.html
> src/bin/pgaccess/doc/html/tutorial/copyright.html: GNU tar archive
> [bruder@mapi2 postgresql-7.1.2]$ tar -tvf
>src/bin/pgaccess/doc/html/tutorial/copyright.html
On Mon, 18 Jun 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > FROM note_links nl, notes n LEFT JOIN calendar c ON (n.nid = c.nid)
> > WHERE (n.type = 'A' OR n.type = 'N' OR n.type = 'H' OR n.type = 'C')
> > AND (nl.id = 15748 AND contact_lvl = 'c
Write very optimized statements and run them infrequently ;)
I don't really think it's possible. You need to understand how your
application will be used, what the resource costs are, and plan
accordingly, (load balance, etc.)
-r
At 05:00 PM 6/18/01 +, gabriel wrote:
>Hello All.
>
>Ho
"Joe Conway" <[EMAIL PROTECTED]> writes:
> Attached is a patch for a new NullTest node type for review and comment.
I assume you are just looking for review at this point; I would not
recommend applying to CVS until the BooleanTest part is done too.
(Since parsetree changes affect stored rules, t
I think that using INNER JOIN between nl and n (on n.nid=nl.nid) or
joining those tables in a subquery might work.
On Mon, 18 Jun 2001, The Hermit Hacker wrote:
> Is there some way to write the above so that it evaluates:
>
> WHERE (n.type = 'A' OR n.type = 'N' OR n.type = 'H' OR n.ty
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> FROM note_links nl, notes n LEFT JOIN calendar c ON (n.nid = c.nid)
> WHERE (n.type = 'A' OR n.type = 'N' OR n.type = 'H' OR n.type = 'C')
> AND (nl.id = 15748 AND contact_lvl = 'company')
> AND n.nid = nl.nid
>
Morning ...
I'm trying to wrack my brain over something here, and no matter
how I try and look at it, I'm drawing a blank ...
I have two tables that are dependent on each other:
notes (86736 tuples) and note_links (173473 tuples)
The relationship is that one no
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> About "I don't want to download all this stuff I can't read": We already
> have chunked distribution tarballs. It would be possible to "chunk out"
> the files pertaining to a particular language
That works for picking up tarballs, but (AFAIK) not f
On Mon, 18 Jun 2001, Peter Eisentraut wrote:
> Tatsuo Ishii writes:
>
> > Hi, some PostgreSQL users in Japan have been translating 7.1 docs into
> > Japanese. I hope the work would finish within 1-2 months. My question
> > is how the translated docs could be merged into the doc source tree
> > on
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> I mean, that it is probably not useful to maintain distribution statistics
> for a table that is that small at all (e.g. <= 3000 rows and less than
> 512 k size).
Actually, stats are quite interesting for smaller tables too. Maybe not
so mu
> > Because we do not want the dba to decide which statistics are optimal,
> > there should probably be an analyze helper application that is invoked
> > with "vacuum analyze database optimal" or some such, that also decides
> > whether a table was sufficiently altered to justify new stats gathe
> > The point is, that if the combined effort of all "hackers" (with the
> > help of some large scale users) cannot come to a more or less
> > generally adequate answer, the field dba most certainly won't eighter.
>
> True, but I regard your "if" as unproven. The reason for this call for
> alph
> > 3. if at all, an automatic analyze should do the samples on small tables,
> > and accurate stats on large tables
>
> Other way 'round, surely? It already does that: if your table has fewer
> rows than the sampling target, they all get used.
I mean, that it is probably not useful to maintai
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> And on what are you going to base "sufficiently altered"?
> Probably current table size vs table size in statistics and maybe
> timestamp when statistics were last updated. Good would also be the
> active row count, but we don't have cheap ac
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> I tried to setup postgresql from current cvs and got
> initdb failure:
You may need to do a full recompile; I've been altering some in-memory
data structures recently. If you don't enable dependency tracking,
you definitely need "make clean" and rebuil
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> we could move the english docs out of pgsql itself and into this module
> too, as:
> pgsql-docs/en
Hmm, I'm not sure that that's a good idea; seems it would lose the
coupling between versions of the source and versions of the
documentation.
I quite
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Imho that is not optimal :-) ** ducks head, to evade flying hammer **
> 1. the random sample approach should be explicitly requested with some
> syntax extension
I don't think so ... with the current implementation you *must* do
approximate A
Tatsuo ... setting up a seperate CVS module for this does sound like a
great idea ... you already have access to the CVS repository, right? Can
you send me a tar file containing what you have so far, and I'll get it
into CVS and then you'll be able to update that at will?
If we set it up as:
p
> Let's switch 'timestamp with time zone' back to 'timestamp'. This just
> makes no sense.
Imho it only makes no sense, since the impl does not conform to standard :-(
The "with time zone" requests, that the client timezone be stored in the row.
The "timestamp" wants no timezone arithmetic/input
First of all thanks for the great effort, it will surely be appreciated :-)
> * On large tables, ANALYZE uses a random sample of rows rather than
> examining every row, so that it should take a reasonably short time
> even on very large tables. Possible downside: inaccurate stats.
> We need to f
> "Dave Cramer" <[EMAIL PROTECTED]> writes:
> > Can the version # of
> > the row be made available to the client?
>
> There is no "version # of the row" in postgres, unless you
> set up such a
> thing for yourself (which could certainly be done, using triggers).
And in addition there is no row
31 matches
Mail list logo
