Cool, thanks.
PostgreSQL 7.4.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3
20030502 (Red Hat Linux 3.2.3-20)
Richard Huxton wrote:
SELECT version();
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Bryce Nesbitt (mailing list account) wrote:
Tom Lane wrote:
As a general rule, you need to be more specific than that about which
version you are working with ;-)
Oooh, I'd be so happy to. But I don't know. Yes, I don't know.
I know which version of "psql" is installed on my local machin
Tom Lane wrote:
But postgres 7 rejects this with "ERROR: cannot cast type character
varying to integer".
As a general rule, you need to be more specific than that about which
version you are working with ;-)
You may find that username::text::integer will work, depending on
Bryce W Nesbitt <[EMAIL PROTECTED]> writes:
> SELECT username,last_name
> FROM eg_member ORDER BY username::integer;
> But postgres 7 rejects this with "ERROR: cannot cast type character
> varying to integer".
As a general rule, you need to be more specific than that about which
version you
Check out the function to_number()
In particular here's an example...
If a field named section is text containing numbers:
ORDER BY to_number(t.section, text())
If the field can also contain non-numerals such as 3a, 3b, and you want
3a to show first then do this:
ORDER BY to_number(t.s
On Wed, 1 Sep 2004, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > The cast to text, however, is part of the data model, and it has to be
> > both natural and universal. I think you agree that there is no
> > universal, obvious correspondence between character strings and boo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The cast to text, however, is part of the data model, and it has to be
> both natural and universal. I think you agree that there is no
> universal, obvious correspondence between character strings and boolean
> values, at least not nearly as unive
sad wrote:
On Wednesday 01 September 2004 10:38, Michael Glaesemann wrote:
On Sep 1, 2004, at 2:41 PM, sad wrote:
On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
There's a fairly accepted convention for integer representations.
There's no such convention for boolean representations.
then
On Wed, 1 Sep 2004, sad wrote:
> > There's a difference between an output function and a cast to text.
> > One gives you an external representation of the data for end use. The
> > other gives you an internal representation for manipulation.
>
> And at the same time
>
> 't'::TEXT can be casted t
> There's a difference between an output function and a cast to text.
> One gives you an external representation of the data for end use. The
> other gives you an internal representation for manipulation.
And at the same time
't'::TEXT can be casted to BOOL
't'::BOOL
but reverse.
On Wed, 1 Sep 2004, sad wrote:
> On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
> > On Wed, 1 Sep 2004, sad wrote:
> > > On Tuesday 31 August 2004 17:49, Michael Glaesemann wrote:
> > > > On Aug 31, 2004, at 8:24 PM, sad wrote:
> > > > > and i am still desire to know _WHY_ there are n
On Sep 1, 2004, at 2:55 PM, sad wrote:
On Wednesday 01 September 2004 10:38, Michael Glaesemann wrote:
On Sep 1, 2004, at 2:41 PM, sad wrote:
On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
There's a fairly accepted convention for integer representations.
There's no such convention for b
sad wrote:
> since you printed it you poke a convention (of casting to string)
>
> if you can print it on screen why not to print it in string?
Allow me an attempt at a philosophical explanation:
The external representation to the API is arbitrary, because it's part
of the API specification, and
On Wednesday 01 September 2004 10:38, Michael Glaesemann wrote:
> On Sep 1, 2004, at 2:41 PM, sad wrote:
> > On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
> >> There's a fairly accepted convention for integer representations.
> >> There's no such convention for boolean representations.
On Sep 1, 2004, at 2:41 PM, sad wrote:
On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
There's a fairly accepted convention for integer representations.
There's no such convention for boolean representations.
then why do you print its value on a screen ?!
Perhaps because if you don't pri
On Wednesday 01 September 2004 09:24, Stephan Szabo wrote:
> On Wed, 1 Sep 2004, sad wrote:
> > On Tuesday 31 August 2004 17:49, Michael Glaesemann wrote:
> > > On Aug 31, 2004, at 8:24 PM, sad wrote:
> > > > and i am still desire to know _WHY_ there are no predefined cast for
> > > > BOOL ?
> > >
On Wed, 1 Sep 2004, sad wrote:
> On Tuesday 31 August 2004 17:49, Michael Glaesemann wrote:
> > On Aug 31, 2004, at 8:24 PM, sad wrote:
> > > and i am still desire to know _WHY_ there are no predefined cast for
> > > BOOL ?
> > > and at the same time there are predefined casts for INT and FLOAT...
On Tuesday 31 August 2004 17:49, Michael Glaesemann wrote:
> On Aug 31, 2004, at 8:24 PM, sad wrote:
> > and i am still desire to know _WHY_ there are no predefined cast for
> > BOOL ?
> > and at the same time there are predefined casts for INT and FLOAT..
>
> I think the main reason is what is
On Tuesday 31 August 2004 16:22, Geoffrey wrote:
> sad wrote:
> > you wrote:
> >>you can use CREATE CAST to make your own cast from boolean to text.
> >
> > thnx it helps.
> >
> > and i am still desire to know _WHY_ there are no predefined cast for BOOL
> > ? and at the same time there are predefin
On Aug 31, 2004, at 8:24 PM, sad wrote:
and i am still desire to know _WHY_ there are no predefined cast for
BOOL ?
and at the same time there are predefined casts for INT and FLOAT..
I think the main reason is what is the proper textual representation of
BOOLEAN? True, PostgreSQL returns 't'
sad wrote:
you wrote:
you can use CREATE CAST to make your own cast from boolean to text.
thnx it helps.
and i am still desire to know _WHY_ there are no predefined cast for BOOL ?
and at the same time there are predefined casts for INT and FLOAT..
I'd like to understand in what context you w
you wrote:
> you can use CREATE CAST to make your own cast from boolean to text.
thnx it helps.
and i am still desire to know _WHY_ there are no predefined cast for BOOL ?
and at the same time there are predefined casts for INT and FLOAT..
---(end of broadcast)
On Aug 31, 2004, at 6:06 PM, sad wrote:
why BOOL can not be casted to TEXT
nevertheless BOOL has a textual (output) representation 't' and
'f' letters
why not to use this fact to define cast to TEXT ?
I'm not sure of the reason why there isn't a built-in cast from boolean
to text, though I'm
Joe Conway <[EMAIL PROTECTED]> writes:
> Not possible in current releases, but it will be in 7.4 (about to start beta).
> It looks like this:
Well there is the int_array_aggregate function in the contrib/intagg
directory. It has to be compiled separately, and it has a few quirks (like the
arrays
Mike Rylander wrote:
Thank you! This is great news. Is there a projected release date for 7.4?
Not exactly an officially projected date, but in the past IIRC beta/RC
has lasted 2 to 3 months, so I'd start looking for a 7.4 release in October.
Also, is there a published roadmap, or should I just
Thank you! This is great news. Is there a projected release date for 7.4?
Also, is there a published roadmap, or should I just get on the developers
list?
Thanks again.
---
Mike Rylander
On Friday 18 July 2003 05:34 pm, Joe Conway wrote:
> Mike Rylander wrote:
> > I have a rather odd table
Mike Rylander wrote:
I have a rather odd table structure that I would like to simplify to be a view
(for some definition of simplify). The current idea I have is to shovel
values from multiple rows in one table into an array in the view. The tables
look something like this:
Is anything like
Antti Haapala <[EMAIL PROTECTED]> writes:
> It's also Debian (3.0).
On investigation the interval_time() function was completely broken for
the --enable-integer-datetimes case --- it was reducing the interval
value modulo one second, rather than modulo one day as intended.
I also noticed that neit
Antti Haapala <[EMAIL PROTECTED]> writes:
> '--enable-integer-datetimes' (could be this?)
Bingo. I can reproduce it with that configure choice.
Should have the answer soon ...
regards, tom lane
---(end of broadcast)---
TIP
Dnia 2003-06-16 17:17, Użytkownik Tom Lane napisał:
What do you get from "pg_config --configure"? What's the hardware
platform --- i386, or something else? Can anyone else reproduce this,
on any platform?
The platform is i386.
There was no "pg_config" file in binary package. After copying this
On Mon, 16 Jun 2003, Tom Lane wrote:
> Tomasz Myrta <[EMAIL PROTECTED]> writes:
> > Dnia 2003-06-16 16:53, U¿ytkownik Tom Lane napisa³:
> > > Tomasz Myrta <[EMAIL PROTECTED]> writes:
> > >
> > > > psql (PostgreSQL) 7.3.2
> > > > SELECT cast(cast('1 day 12 hours' as interval) as time);
> > > > tim
Tomasz Myrta <[EMAIL PROTECTED]> writes:
> Dnia 2003-06-16 16:53, U¿ytkownik Tom Lane napisa³:
>> Tomasz Myrta <[EMAIL PROTECTED]> writes:
>>
>>> psql (PostgreSQL) 7.3.2
>>> SELECT cast(cast('1 day 12 hours' as interval) as time);
>>> time
>>> --
>>> 00:00:00
>>> (1 row)
>>
>>
>> I get 1
Dnia 2003-06-16 16:53, Użytkownik Tom Lane napisał:
Tomasz Myrta <[EMAIL PROTECTED]> writes:
psql (PostgreSQL) 7.3.2
SELECT cast(cast('1 day 12 hours' as interval) as time);
time
--
00:00:00
(1 row)
I get 12:00:00 here, using 7.3.3 ... platform-specific problem maybe?
Default Debian p
Tomasz Myrta <[EMAIL PROTECTED]> writes:
> psql (PostgreSQL) 7.3.2
> SELECT cast(cast('1 day 12 hours' as interval) as time);
>time
> --
> 00:00:00
> (1 row)
I get 12:00:00 here, using 7.3.3 ... platform-specific problem maybe?
regards, tom lane
>
> Hi all.
> Recently I face some problem with casting character type variable and
> varchar variable.
> The situation was like: I had 2 table, on table A, the user_name is
defined
> as character(32), and table B uses varchar(32). I have 1 function and
a
> trigger to manipulate with these data.
>
On November 26, 2002 02:19 pm, Thomas Good wrote:
> Having perused all the online docs I can find it appears there is no
> SQL solution for casting the dread money type to numeric.
> Is this true?
>
> select rent::numeric(9,2) from x;
> ERROR: Cannot cast type 'money' to 'numeric'
Fraid so. That'
> select not count(*) = 0 from my_table;
>
> Basically, for any integer i, convert to boolean with: not i = 0
Or i != 0 of course...
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "
On Fri, 16 Aug 2002, Bhuvan A wrote:
> How do i cast an integer value to boolean?
You can always do something like this:
select not count(*) = 0 from my_table;
Basically, for any integer i, convert to boolean with: not i = 0
--
Tod McQuillin
---(end of broadcast)---
On Mon, Apr 09, 2001 at 06:53:13PM +0200, Peter Eisentraut wrote:
> Ross J. Reedstrom writes:
>
> > FYI, I can't find an occurance of '::' that's not part of '::=' in either
> > SQL1992.txt or the ansi-iso-[sql]-1999.txt files I've got.
>
> SQL 1999 6.12
>
> ::=
> [ ]
>
Ah, right: M
Ross J. Reedstrom writes:
> FYI, I can't find an occurance of '::' that's not part of '::=' in either
> SQL1992.txt or the ansi-iso-[sql]-1999.txt files I've got.
SQL 1999 6.12
::=
[ ]
That syntax even makes sense...
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/pe
On Mon, Apr 09, 2001 at 05:57:45PM +0200, Peter Eisentraut wrote:
> Cedar Cox writes:
>
> > When would one want to use cast()? What is the difference between cast
> > and :: ? After a quick look in the documentation I couldn't find
> > anything..
>
> cast() is SQL, :: is traditional Postgres.
Cedar Cox writes:
> When would one want to use cast()? What is the difference between cast
> and :: ? After a quick look in the documentation I couldn't find
> anything..
cast() is SQL, :: is traditional Postgres. :: may go away in the distant
future to make room for the SQL feature that is s
On Sun, 8 Apr 2001, Peter Eisentraut wrote:
> Hans-Jürgen Schönig writes:
>
> > Is there any possibility to cast numeric to text in Postgres 7.0.3?
> >
> > shop=# select cast(price as text) from products;
> > ERROR: Cannot cast type 'numeric' to 'text'
>
> Use the to_char() function.
When w
Hans-Jürgen Schönig writes:
> Is there any possibility to cast numeric to text in Postgres 7.0.3?
>
> shop=# select cast(price as text) from products;
> ERROR: Cannot cast type 'numeric' to 'text'
Use the to_char() function.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter
Thomas SMETS writes:
> I'm removing charaters from a String which should be numbers.
> I then want to make calculations on these numbers (calculate the ISBN
> number).
(You might want to look into contrib/isbn_issn for an isbn type.)
> Do I have to cast the char into int's before I can do the c
45 matches
Mail list logo
