On Thu, Oct 22, 2009 at 2:41 PM, the6campbells wrote:
> Question.. is there a way that I can get Postgres to return the tz as
> supplied on the insert statement
PostgreSQL converts the timezone to GMT and stores it with no offset,
then adds an offset based on the TZ of the client requesting it ba
the6campbells writes:
> Why is Postgres returning a timestamp instead of the expected date data type
> for the first expression (the second returns a date)?
> select date '2001-03-30' - interval '1' year, date '2001-03-30' - integer
> '365' from tversion
Would you expect a date for
date
the6campbells writes:
> Question.. is there a way that I can get Postgres to return the tz as
> supplied on the insert statement
No.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgres
Why is Postgres returning a timestamp instead of the expected date data type
for the first expression (the second returns a date)?
In other words, is this a known bug or is it design intent. The manuals did
not seem to appear to say this is intentional behaviour but is not SQL
standard.
select da
Question.. is there a way that I can get Postgres to return the tz as
supplied on the insert statement
insert into TTSTZ(RNUM, CTSTZ) values ( 0, null);
insert into TTSTZ(RNUM, CTSTZ) values ( 1, timestamp with time zone
'2000-12-31 12:00:00.0-05:00');
insert into TTSTZ(RNUM, CTSTZ) values ( 2, ti
Gary Chambers writes:
> /* Here is where I am stuck trying to fill data
>I've tried:
>data.term_count.coord_type := S;
>(data.term_count).coord_type := S;
>data.(term_count.coord_type) := S;
> */
I'm afraid plpgsql isn't tremendousl
All...
Given the following [hopefully] relevant portions of a function:
CREATE OR REPLACE FUNCTION solve(FLOAT8, VARCHAR, CHAR)
RETURNS SETOF sometype_t AS
$solve$
DECLARE
data sometype_t;
...
BEGIN
FOR term_count IN
SELECT DISTINCT coord_type AS coord_type, MAX(term) AS maxterms
Denis BUCHER writes:
> To do this it will be a little complicated because of table
> dependencies... And it could bug again at the next DROP COLUMN... Is
> there a way to change my function (RETURN SETOF part) to specify the
> column names/types ?
No, not really. You could maybe un-drop the colu
Richard Huxton writes:
> Tom Lane wrote:
>> plpgsql isn't tremendously good with rowtypes that contain dropped
>> columns.
> I thought that only applied to columns dropped after the function was
> defined. Live and learn.
There are/were some variants that go away if you recreate the function
o
Hi Tom,
Another question :
Tom Lane a écrit :
> Denis BUCHER writes:
>> I have a strange problem, because it worked in a fonction for a table,
>> and now I created the same (?) function for another table and it doesn't
>> work...
>
>> The function is accepted but at runtime I get :
>
>> ERREUR
Tom Lane wrote:
> Denis BUCHER writes:
>
> Does that table have any dropped columns? If you don't remember
> whether you ever dropped any columns, a quick look into pg_attribute
> will tell you:
> select attname from pg_attribute where attrelid =
> 'rma.serial_number'::regclass;
>
> plpgsql is
Denis BUCHER wrote:
>> Bienvenue dans psql 8.1.17, l'interface interactive de PostgreSQL.
OK - I'm not aware of any problems in that version. You're only one
revision from the latest 8.1.x series.
> OK I prepared what you asked and I tested it myself before sending.
>
> And I think I've found th
Hello Tom,
Tom Lane a écrit :
> Denis BUCHER writes:
>> I have a strange problem, because it worked in a fonction for a table,
>> and now I created the same (?) function for another table and it doesn't
>> work...
>
>> The function is accepted but at runtime I get :
>
>> ERREUR: wrong record t
Richard Huxton a écrit :
>>> The other thing you could try is printing out row before returning it:
>>> RAISE NOTICE 'row = %', row;
>>> RETURN NEXT ROW;
>>> It might be you've not got what you were expecting.
>> Thanks a lot, good idea...
>>
>> But it looks good :
>
> Hmm...
>
>>> SELECT * F
Denis BUCHER writes:
> I have a strange problem, because it worked in a fonction for a table,
> and now I created the same (?) function for another table and it doesn't
> work...
> The function is accepted but at runtime I get :
> ERREUR: wrong record type supplied in RETURN NEXT
> CONTEXTE : P
Denis BUCHER wrote:
> Richard Huxton a écrit :
>> The other thing you could try is printing out row before returning it:
>> RAISE NOTICE 'row = %', row;
>> RETURN NEXT ROW;
>> It might be you've not got what you were expecting.
>
> Thanks a lot, good idea...
>
> But it looks good :
Hmm...
>
Hello Richard,
Richard Huxton a écrit :
>> I saw somwhere it could be the order of the fields ?
>
> Not if you are doing "SELECT * FROM".
>
> Create an empty test database and a short script to create the table and
> function, insert a couple of rows then call the function. If you wrap
> the who
Denis BUCHER wrote:
> I saw somwhere it could be the order of the fields ?
Not if you are doing "SELECT * FROM".
Create an empty test database and a short script to create the table and
function, insert a couple of rows then call the function. If you wrap
the whole thing in BEGIN ... ROLLBACK we
Hello Richard,
Richard Huxton a écrit :
ERREUR: wrong record type supplied in RETURN NEXT
CONTEXTE : PL/pgSQL function "hds_bw_find_sn_live" line 26 at return next
Does someone maybe knows what it could be ?
This is (a part of) my function :
> CREATE OR REPL
Denis BUCHER wrote:
> Richard Huxton a écrit :
>>> ERREUR: wrong record type supplied in RETURN NEXT
>>> CONTEXTE : PL/pgSQL function "hds_bw_find_sn_live" line 26 at return next
>>>
>>> Does someone maybe knows what it could be ?
>>>
>>> This is (a part of) my function :
>>>
CREATE OR REPLAC
Hello, (CORRECTED VERSION OF MY PREVIOUS EMAIL)
I have a strange problem, because it worked in a fonction for a table,
and now I created the same (?) function for another table and it doesn't
work...
The function is accepted but at runtime I get :
ERREUR: wrong record type supplied in RETURN NE
Richard Huxton a écrit :
>> ERREUR: wrong record type supplied in RETURN NEXT
>> CONTEXTE : PL/pgSQL function "hds_bw_find_sn_live" line 26 at return next
>>
>> Does someone maybe knows what it could be ?
>>
>> This is (a part of) my function :
>>
>>> CREATE OR REPLACE FUNCTION rma.find_sn_live (v
Denis BUCHER wrote:
>
> ERREUR: wrong record type supplied in RETURN NEXT
> CONTEXTE : PL/pgSQL function "hds_bw_find_sn_live" line 26 at return next
>
> Does someone maybe knows what it could be ?
>
> This is (a part of) my function :
>
>> CREATE OR REPLACE FUNCTION rma.find_sn_live (varchar(
Hi
maboyz schrieb:
I am in the process of migrating our database from MS Server 2000 to
Postgres. I have a bunch of stored procs which i have to modify the syntax
so they work in postgresql. My ? is is there an equivalent for the @@Error
function in T-SQL for postgres: The stored proc i am conve
Hello,
I have a strange problem, because it worked in a fonction for a table,
and now I created the same (?) function for another table and it doesn't
work...
The function is accepted but at runtime I get :
ERREUR: wrong record type supplied in RETURN NEXT
CONTEXTE : PL/pgSQL function "hds_bw_f
25 matches
Mail list logo
