The following bug has been logged online:
Bug reference: 3597
Logged by: Luiz K. Matsumura
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Fedora core 3
Description:CREATE OR REPLACE VIEW
Details:
scenario:
CREATE TABLE table1
(
id
The following bug has been logged online:
Bug reference: 3598
Logged by: Luiz K. Matsumura
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Fedora Core 3
Description:Strange behaviour of character columns in select with
views
Details:
Heikki Linnakangas wrote:
Luiz K. Matsumura wrote:
When we do a command Create or Replace View that change columns of previous
view we got a error.
Right. You can't change the data types of an existing view. You'll have
to drop and recreate it.
But, with the 'replace' command,
Luiz K. Matsumura wrote:
Heikki Linnakangas wrote:
Luiz K. Matsumura wrote:
When we do a command Create or Replace View that change columns of
previous
view we got a error.
Right. You can't change the data types of an existing view. You'll have
to drop and recreate it.
But, with
Luiz K. Matsumura wrote:
When we do:
SELECT * from view1;
OR
SELECT id,col1,type1,type2 FROM view1;
column type1 return as bpchar
But if we do:
SELECT type1 FROM view1;
or
SELECT id,col1,type2,type1 FROM view1;
Now, type1 return as character(3) as expected.
I can't reproduce
The following bug has been logged online:
Bug reference: 3599
Logged by: Alexis Beuraud
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: Windows 2000 Professional
Description:Wrong search_path inside a function
Details:
The function 'set
Heikki Linnakangas [EMAIL PROTECTED] writes:
I can't reproduce this. View1.type1 has has type char(3) as expected in
both cases, as witnessed by CREATE VIEW f AS SELECT */type1 FROM
view1; \d f. How did you determine the data types?
I just did reproduce it: libpq's PQfmod() does report either
Alexis Beuraud [EMAIL PROTECTED] writes:
EXECUTE (' set search_path to ' || p_schemaName ); setting the search
path here!
FOR result in
select i
from TableT
loop
return next result;
END LOOP;
The reason that doesn't do what you expect is that the plan for the
SELECT is cached
On Tue, 2007-09-04 at 07:42 +, Luiz K. Matsumura wrote:
When we do a command Create or Replace View that change columns of
previous view we got a error.
Right. Many folks consider views to be a sort of API to the database.
Using views to provide an API substantially insulates client code
Wow, I learn a lot about views now
Sorry for my confusion. You are right, my reasoning is very limited.
Thanks Heikki , Tom and Reece by yours answers.
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Luiz K. Matsumura wrote:
But, with the 'replace' command, this isn't
Heikki Linnakangas wrote:
Luiz K. Matsumura wrote:
When we do:
SELECT * from view1;
OR
SELECT id,col1,type1,type2 FROM view1;
column type1 return as bpchar
But if we do:
SELECT type1 FROM view1;
or
SELECT id,col1,type2,type1 FROM view1;
Now, type1 return as character(3) as expected.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Heikki Linnakangas kirjoitti:
Jukka Holappa wrote:
I can't easily reproduce this problem but it happens in every few hours in
my use.
Can you get a core dump and/or a stack trace out of it? I noted that
you're running Gentoo, so
The following bug has been logged online:
Bug reference: 3600
Logged by: Phillip Carruthers
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.16
Operating system: Redhat 4
Description:ODBC Driver not working with BIGINT
Details:
When using SQLBindParameter
Hi.
Umm, I have not reproduced a problem...
Would you be shown the reproducible code?
and what Version of psqlODBC.?
Regards,
Hiroshi Saito
From: Phillip Carruthers [EMAIL PROTECTED]
The following bug has been logged online:
Bug reference: 3600
Logged by: Phillip
14 matches
Mail list logo
