"Traci Sumpter" <[EMAIL PROTECTED]> writes:
> Cheesy one here
Got a cheesy answer for you --- cast the result ...
regression=# create view voo as
regression-# select f1::varchar(20) from
regression-# (select f1 from foo union select f2 from foo) ss;
CREATE VIEW
regression=# \d voo
Cheesy one here
I created a view similar to
Select field1, field2 from table
where field3 = 'Fred'
UNION
Select field1, field2 from table
where field3 = 'Wilma';
When the view contains just one sql statement the field definitions e.g.
charater varying (20) however when both a
One way to do this is to use the column_info database handle method.
Here's a little perl script that accepts a table name as an argument
and returns the column names:
#!/usr/bin/perl
use DBI;
use strict;
my( $database, $table ) = @ARGV;
my $dbh = DBI->connect( "dbi:Pg:dbname=$database", 'postgre
On Aug 31, 2004, at 1:23 PM, Manuel Sugawara wrote:
I have SQL highlighting, but what I want are colors for the PL/pgSQL
key words. It would make PL programming much easier.
Since the Pl/PgSQL code is quoted (x)emacs paints the whole thing
using the string face. Delete one of the apostrophes delim
select replace( replace( replace( replace( 'Test ä ö ü ß', 'ä','ae'),
'ö','oe' ), 'ü','ue'), 'ß','ss' );
Thanks a lot. A wrote this into a user defined function with lower()
around the source string, and it works. :-)
CREATE OR REPLACE FUNCTION public.unumlaut(varchar)
RETURNS varchar AS
'sele
Hi community,
I would like to retrieve all the fieldnames of a given table. In the
perl module Tie::DBI[1] i found the following fragment:
$dbh->prepare("LISTFIELDS $table");
in the case the DB supports this (Tie::DBI thinks so for Pg) or the
alternative is:
$dbh->prepare("SELECT * FROM
One solution:
select replace( replace( replace( replace( 'Test ä ö ü ß', 'ä','ae'), 'ö','oe' ),
'ü','ue'), 'ß','ss' );
replace
--
Test ae oe ue ss
If you also have upcase-characters, you have to extend the statement.
Robert Strötgen schrieb:
I want to query words with German
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
I want to query words with German "umlauts" (special characters) with
and without normalization. I want to find "grün" (green) written
"gruen" as well.
Using "LIKE" with locale de_DE.iso88591 or .utf-8 does not help (Locale
support should affect "LIKE",
http://www.postgresql.org/docs/7.3/static/ch
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
> select 't'::text::bool;
> ERROR: cannot cast type text to boolean
>
> If you're thinking 't'::bool, that's something different.
Ok
i have nothing to opppose
and by the way (!!!)
why TEXT can not be casted to REGCLASS ?
---(end of broadcast)---
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
16 matches
Mail list logo
