> The first and second items here seem to be perfectly clear that the
> names t1 and t2 have scope across the whole SELECT statement and are not
> hidden within the formed by the OUTER JOIN clause.
You are right. If there is a "correlation name", then those underlying
table names become invisibl
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> It works for me:
>> regression=# select t1.*, t2.* from t1 natural left outer join t2;
>> id | id2 | id
>> +-+
>> 1 | 1 | 1
> My recollection is that SQL9x requires that the join result lose the
> link to the original table names. That
http://www.heartlight.org/cgi-shl/todaysverse.cgi?day=20001215
===
Created by Mail2Sig - http://pdunford.godzone.net.nz/software/mail2sig/
"mike" <[EMAIL PROTECTED]> writes:
> Is ther any info on using toast as of yet, and if so where is it hidden to?
There isn't any yet, but you don't really need it. Just declare
your tables and away you go. No User-Serviceable Parts Inside ;-)
regards, tom lane
In recent months there has been a great deal of speculation,
confusion and concern raised in the open source community over
the roles of commercial companies and the PostgreSQL project.
There has also been a lot of curiosity and noise around who
and what PostgreSQL, Inc. (PgSQL) is...
As a resp
I've been getting these for about 6 hours now:
cvs server: [18:58:27] waiting for anoncvs's lock in /home/projects/pgsql/cvsroot/pgsql
Can someone kill off this lock so I can commit?
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Is ther any info on using toast as of yet,
and if so where is it hidden
to?
OK, compatibility mapping removed.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > That was me. The old code did old -> current, so I changed it to do
> > current -> old. How else can I fix this? Attached is the old patch.
>
> But CURRENT was strictly an internal token name, not a string the
Bruce Momjian writes:
> > peter=# select 1 as current;
> > old
> > -
> >1
> >
> > This is now the inverse of what it used to do, but it's still not what it
> > *should* do. I see someone already tried to fix that (keywords.c 1.76 ->
> > 1.77, TODO list), but he should try again.
>
> Tha
Tom Lane wrote:
...
>Short of a major restructuring of inherited-column creation, I see
>no good solution to this. I see two bad solutions:
>
>1. Require that the referenced column be marked NOT NULL already,
>so that the constraint will be inherited properly from the parent.
>In othe
Bruce Momjian <[EMAIL PROTECTED]> writes:
> That was me. The old code did old -> current, so I changed it to do
> current -> old. How else can I fix this? Attached is the old patch.
But CURRENT was strictly an internal token name, not a string the user
could actually see. So there's no need t
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> We'd still want XID keys for the locks that are used to wait for a
>> particular transaction to complete (eg when waiting to update
>> a tuple). I think that's OK since VACUUM doesn't need to hold any
>> such locks, but it'd probably mean making sep
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> peter=# select 1 as current;
> old
> -
>1
> This is now the inverse of what it used to do, but it's still not what it
> *should* do. I see someone already tried to fix that (keywords.c 1.76 ->
> 1.77, TODO list), but he should try again.
W
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, I see from the CVS logs you say:
> Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias.
> (Don't forget that an alias is required.) Views reimplemented as expanding
> to subselect-in-FROM. Grouping, aggregates, DISTINCT in v
Tom, I see from the CVS logs you say:
Subselects in FROM clause, per ISO syntax: FROM (SELECT ...) [AS] alias.
(Don't forget that an alias is required.) Views reimplemented as expanding
to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually
work now (he says optimistically).
> We'd still want XID keys for the locks that are used to wait for a
> particular transaction to complete (eg when waiting to update
> a tuple). I think that's OK since VACUUM doesn't need to hold any
> such locks, but it'd probably mean making separate lmgr API entry
> points for those locks as
> I can work on this if you don't have time to...
I have no -:)
Vadim
> peter=# select 1 as current;
> old
> -
>1
>
> This is now the inverse of what it used to do, but it's still not what it
> *should* do. I see someone already tried to fix that (keywords.c 1.76 ->
> 1.77, TODO list), but he should try again.
That was me. The old code did old -> curren
peter=# select 1 as current;
old
-
1
This is now the inverse of what it used to do, but it's still not what it
*should* do. I see someone already tried to fix that (keywords.c 1.76 ->
1.77, TODO list), but he should try again.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Use BackendID instead of XID in XIDTAG?
> Add internal (ie per backend) hash of locks that should not be
> released at commit time?
> And couple additional funcs in lmgr API?
I think that would work. I'm inclined to use backend PID instead of
Backen
OK, I see the problem. You have:
CREATE TABLE person (
id CHAR(10)
);
CREATE TABLE organisation (
...,
PRIMARY KEY (id)
)
INHERITS (person);
ie, a PRIMARY KEY declaration on an inherited column. Normally a
PRIMARY KEY declaration causes the key column to become marked
NOT N
On Fri, Dec 15, 2000 at 03:20:27PM -0500, Bruce Momjian wrote:
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > It seems that Tom has committed his fixups but we're still waiting
> > > on Vadim?
> >
> > Sorry guys, I'm busy with WAL issues currently.
> > CRC will require initdb, so it's
Jan pointed out that elog(FATAL) out of ReverifyMyDatabase() leaves
shared memory in an un-cleaned-up state (buffer refcounts > 0).
There might also be other unaccounted-for problems, I suspect.
I do not like his fix (heap_endscan before the elog(FATAL)) because
it only plugs this specific hole in
I can't reproduce this --- I get
Constraints: ((ptype >= 0) AND (ptype <= 8))
structure = 'L'::bpchar) OR (structure = 'C'::bpchar)) OR (structure
= 'U'::bpchar)) OR (structure = 'O'::bpchar))
(((department ISNULL) AND (parent_id ISNULL)) OR ((department > ''::text)
> > Sorry guys, I'm busy with WAL issues currently.
> > CRC will require initdb, so it's better to implement it
> > first...
> > Also, is TOAST-table vacuuming fixed now?
>
> Can someone please remind me? CRC allows us to know of WAL log is
> corrupt?
Currently WAL has no means to know is log d
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> If you like I'll post the patch, but it strikes me as a waste of list
> >> bandwidth --- anyone who is likely to actually review it is perfectly
> >> capable of doing cvs diff for themselves ...
>
> > Posting patch is only useful if you want people
[ Charset ISO-8859-1 unsupported, converting... ]
> > It seems that Tom has committed his fixups but we're still waiting
> > on Vadim?
>
> Sorry guys, I'm busy with WAL issues currently.
> CRC will require initdb, so it's better to implement it
> first...
> Also, is TOAST-table vacuuming fixed no
> > Also, is TOAST-table vacuuming fixed now?
>
> Still broken. Hiroshi had muttered something about fixing
> the internal commit of VACUUM so that it's more like a real
> commit --- including advancing the transaction ID --- but
> still doesn't release the exclusive lock held by VACUUM.
> Basi
* Bruce Momjian <[EMAIL PROTECTED]> [001215 10:34] wrote:
> >
> > sorry, meant to respond to the original and deleted it too fast ...
> >
> > Tom, if the difference between 7.0 and 7.1 is such that there is a
> > performance decrease, *please* apply the fix ... with the boon that OUTER
> > JOIN
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> If you like I'll post the patch, but it strikes me as a waste of list
>> bandwidth --- anyone who is likely to actually review it is perfectly
>> capable of doing cvs diff for themselves ...
> Posting patch is only useful if you want people to review i
"Oliver Elphick" wrote:
>In the creation below, the column parent_id has ended up with a NOT NULL
>constraint that I didn't ask for and don't want.
If I change the order of the columns, the NOT NULL constraint always ends
up on the last column.
This is not the only table to be affected.
Ev
Bruce Momjian <[EMAIL PROTECTED]> writes:
> My quick question is that if we have a1=b1 and b1=c1, isn't the join
> sorted by a1, b1, and c1, and threfore we don't get more sorted plans?
That's not the issue. See, before the transitive-equality patch,
if you wrote
select * from a,b,c whe
> It seems that Tom has committed his fixups but we're still waiting
> on Vadim?
Sorry guys, I'm busy with WAL issues currently.
CRC will require initdb, so it's better to implement it
first...
Also, is TOAST-table vacuuming fixed now?
Vadim
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Also, is TOAST-table vacuuming fixed now?
Still broken. Hiroshi had muttered something about fixing the internal
commit of VACUUM so that it's more like a real commit --- including
advancing the transaction ID --- but still doesn't release the exclu
> What I'm thinking of doing is truncating the recorded pathkeys of a path
> at the first sortkey that's not useful for either a higher-level
> mergejoin clause or the requested final output sort ordering. Then the
> logic inside add_path() wouldn't change, but it would only be considering
> usef
On Fri, 15 Dec 2000, Alfred Perlstein wrote:
> * Bruce Momjian <[EMAIL PROTECTED]> [001215 10:34] wrote:
> > >
> > > sorry, meant to respond to the original and deleted it too fast ...
> > >
> > > Tom, if the difference between 7.0 and 7.1 is such that there is a
> > > performance decrease, *p
In the creation below, the column parent_id has ended up with a NOT NULL
constraint that I didn't ask for and don't want.
This is 7.1, updated today from cvs.
===
[... other tables created ...]
CREATE TABLE person
(
ptype
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Totally agree. In the old days, we posted all our patches to the list
> so people could see. We used to make cvs commits only on the main
> server, so we had the patch handy, and it made sense to post it. Now
> that we have remote cvs, we don't do it
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Totally agree. In the old days, we posted all our patches to the list
> > so people could see. We used to make cvs commits only on the main
> > server, so we had the patch handy, and it made sense to post it. Now
> > that we have remote cvs, we do
On Fri, 15 Dec 2000, Thomas Lockhart wrote:
> Date: Fri, 15 Dec 2000 15:47:01 +
> From: Thomas Lockhart <[EMAIL PROTECTED]>
> To: Oleg Bartunov <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], Tom Lane <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED],
> 'pgsql-hackers ' <[EMAIL PROTECTED]>
> Subj
> REDO @ 0/327312; LSN 0/327560: prev 0/327064; xprev 0/327064; xid 594: Heap -
>insert: node 1
> 8719/18720; cid 0; tid 0/18
> DEBUG: ReadRecord: there is no subrecord flag in logfile 0 seg 0 off 40
^
> DEBUG: Formatting l
Did you perhaps have foreign key constraints with an on delete
clause defined on a table that referenced this one? Postgres doesn't
currently check that the types are comparable before making the
constraint. I'm working on adding a check for that now.
Or for that matter, any other rules or tri
Nick Wayne <[EMAIL PROTECTED]> writes:
> I went thru all the mailing list archives and other
> documentation and found the way to increase the max
> tuple size clearly as " change the BLCKSZ to "
> I did that and even created a new data directory and
> cluster by using init_db but the error
>
But i'm not making any compare.
I just wrote delete from table; and i receive that message.
>>
>> Hmm. We will need to know more about your setup, since a simple
>>
>> delete from table;
>>
>> in psql does not involve *any* comparisons, and should never provoke the
>> message you are
The Hermit Hacker wrote:
>
> beta1 was very low key ... it was announced here on the list as "its
> packaged, try it out" ... there was no big hype about this one, but there
> will be for beta2, which will most likely be after Vadim gets those vacuum
> fixes in place, and Tom gets those planner f
Hi there,
I went thru all the mailing list archives and other
documentation and found the way to increase the max
tuple size clearly as " change the BLCKSZ to "
I did that and even created a new data directory and
cluster by using init_db but the error
psql:ins.sql:173: ERROR: Tuple is too b
Hi,
Can anyone help me .
I want to know how
to write triggers.
i am using java and postgresql
---
From:- |
Ms. Manika Dey.|Ph.No:--
Engineer-SC (Comp. Tech.) | IPR -- 02712 -
Michael Richards wrote:
>
> Okay,
>
> Where would I find a definition of the tuple data? I didn't see anything
> promising in include/storage?
>
> I've found a definition for the page inside pagebuf.h That clears up all the
> page stuff. I'm still having a little trouble decoding the tuple data
> It looks like other people just didn't use index decompression function
> (at least in Gene's code decompression function just do return ) and
> that's why this bug was not discovered. We could make a patch for
> upcoming 7.1 if hackers desired. I consider this patch as a bugfix
> not a new fea
Well,
we found an answer ourserlves. Patch for 7.0.3 is included below.
Credits to Teodor Sigaev ([EMAIL PROTECTED])
Some comments:
>From src/backend/access/gist/gist.c
/*
** Take a compressed entry, and install it on a page. Since we now know
** where the entry will live, we decompress it and
A heap page corruption is not very likely in PostgreSQL because of the
underlying page design. Not even on flakey hardware/ossoftware.
(I once read a page design note from pg 4 but don't exactly remember
were or when)
The point is, that the heap page is only modified in places that were
previou
> > cusejoua=# update journaleintrag set txt_funktion=trim(txt_funktion);
> > FATAL 2: write(logfile 0 seg 2 off 4612096) failed: No such file or directory
> > pqReadData() -- backend closed the channel unexpectedly.
> > This probably means the backend terminated abnormally
> > b
I received that message working directly in psql.
I already send another email, please see.
Regards
Luis Sousa
Thomas Lockhart wrote:
> > But i'm not making any compare.
> > I just wrote delete from table; and i receive that message.
>
> Hmm. We will need to know more about your setup, since
I just trying to execute a simple query in a table to delete a simpe record
or all of them, like:
DELETE * FROM table;
I have a schema of more or less 25 tables, that are created using a script.
When i'm trying to use that table (and only happens in this table) when
created by the script i recei
> > because the cache will be emptied by high priority multiple new rows,
> > thus writing to the end anyways.
>
> Yes, but this only happens when you don't have enought spare idle CPU
> time. If you are in such situation for long periods, there's nothing you
> can do, you already have problems.
55 matches
Mail list logo
