On Tue, 16 Sep 2003, Kris Jurka wrote:
> Something else I've noticed about temp tables is that you are
prohibited
> from having a permanent table contain a foreign key reference to a
temp
> table, but you are allowed to reference a permanent table from a temp
> table. The triggers don't work corre
Kris Jurka <[EMAIL PROTECTED]> writes:
> ... you are allowed to reference a permanent table from a temp
> table. The triggers don't work correctly when the table is
> modified by another backend:
Hmm, yeah. That worked when we put in the temp-vs-permanent check in
foreign key creation, but it do
Tom Lane wrote:
> I think we have two choices: disallow foreign-key references from temp
> tables to permanent tables, or take out the optimization of storing
> temp table pages in private memory. (That would leave the whole
"local
> buffer manager" module as dead code, I think.) I'm kinda leanin
On Wed, 17 Sep 2003, Tom Lane wrote:
> Kris Jurka <[EMAIL PROTECTED]> writes:
> > ... you are allowed to reference a permanent table from a temp
> > table. The triggers don't work correctly when the table is
> > modified by another backend:
>
> I think we have two choices: disallow foreign-key re
On Tue, 16 Sep 2003, Tom Lane wrote:
> This is not a 100% solution to our problems. I don't think we could use
> it to solve the problem for int2 columns ("int2col = 42") because it'd
> be unsafe to promise that an int4-to-int2 cast could be inserted into
> an expression without changing the beha
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> I still think that this is a type inference problem and nothing else.
Well, perhaps ripping out the entire type resolution algorithm and
replacing it with something less ad-hoc is indeed the right long-term
answer. I don't have time to do that though
Hi All,
We have a development server running
OS – Linux development-server
2.4.20-openmosix-r4 #1 SMP Mon May 19 02:32:52 PDT
2003 i686 Intel(R) Xeon(TM) CPU 2.40GHz GenuineIntel GNU/Linux
Database - PostgreSQL 7.3 on
i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.1
We have a ta
On Wed, 17 Sep 2003, Tom Lane wrote:
> Another thing to keep in mind is that it's not always the case that
> assigning the right type to a literal constant would solve the problem.
> We have the same issues with variables; for example, a join with
> "WHERE a.int8col = b.int4col" may fail to take a
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Wed, 17 Sep 2003, Tom Lane wrote:
>> So I'm beginning to think that avoiding cross-type operators is not the
>> right route to a solution anyway. It may be better to leave the parser
>> alone and teach the planner how to switch to the alternate
>>
Tom Lane wrote:
> Dave Smith <[EMAIL PROTECTED]> writes:
> > My point was that it was inconstant behavour. What exactly are you
> > comparing with int2? To me the case without the cast should should throw
> > the same error as the statement with the cast.
>
> > select * from test where f=1981928
Kevin Brown <[EMAIL PROTECTED]> writes:
> Hmm...but what if the cast were to return NULL in the event that the cast
> fails or cannot be done? Would that even be reasonable?
Yeah, I was wondering about that myself. I'd not want to try to use
such an idea in general, but if we find that int2 inde
11 matches
Mail list logo
