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 ser
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---
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:
Sce
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
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
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:
> Luiz K. Matsumura wrote:
>> But, with the 'replace' command, this isn't implicit ?
>> If they found a view, replace the existing view with the new one (on the
>> other words, drop and create again?)
> Replacing is not exactly the same thing as dr
"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 repor
"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
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
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 rec
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 wi
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 Carrut
My colleague Marc Schablewski reported this Bug (#3484) the first time
at the end of July.
The described problem occured twice at our database and now it happened
again.
Summary
==
Various errors like:
"invalid page header in block 8658 of relation",
"could not open segment 2 of relatio
17 matches
Mail list logo
