Re: [GENERAL] Format

[Andreas Joseph Krogh]

På mandag 28. september 2015 kl. 14:45:00, skrev Ramesh T <
rameshparnandit...@gmail.com >:
Hi All,           How to change sql format to look beautiful and 
understandable using pgadmin3 or else ther tools for postgres.
 
any help appreciated..

 
Use IntelliJ IDEA community-edition, which is free: 
https://www.jetbrains.com/idea/download/
 
It is a JAVA-IDE, but the support for PostgreSQL is excellent. It comes with 
syntax-highligting, code-completion, DB-browser etc.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com 
 


 

Re: [GENERAL] Format

[Ramesh T]

On Tue, Sep 29, 2015 at 6:43 PM, Ramesh T 
wrote:

> in my mind to be beautiful ,avoid confusion to understand sql query code
>
> like
>
> select abcd,cde,rfg,count(*),bcd,cde,rfg,count(*),bcd,cde,rfg,count(*) ;
>
> if some one written, then newer or code reader understand easily
> select abcd,
>   cde,
>   rfg,
>   count(*),
> ...,
> ..,
> ...,
> like line by line
>
> in postgres direct option format is not available.i want see code intended
> proper.
> in context editor i didn't find format option only like  lower to upper..
>
>
>
> On Mon, Sep 28, 2015 at 11:20 PM, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> CREATE FUNCTION
>> CREATE VIEW
>>
>> As yes, I am being mostly serious - though I have been pondering seeing
>> what tools can do as opposed to the manual formatting I've been
>> performing.  Even a basic linter would be helpful...
>>
>> The big problem is you need to define what it means to be beautiful.
>> Understandable is a totally different area and that is more where views and
>> functions come in so you can provide names to the various constructs you
>> are using.  CTE/WITH facilitate this as well.
>>
>> David J.
>>
>>
>> On Mon, Sep 28, 2015 at 8:45 AM, Ramesh T 
>> wrote:
>>
>>> Hi All,
>>>   How to change sql format to look beautiful and understandable
>>> using pgadmin3 or else ther tools for postgres.
>>>
>>> any help appreciated..
>>>
>>
>>
>

Re: [GENERAL] Format

[Adrian Klaver]

On 09/29/2015 06:13 AM, Ramesh T wrote:



On Tue, Sep 29, 2015 at 6:43 PM, Ramesh T > wrote:

in my mind to be beautiful ,avoid confusion to understand sql query code

like

select abcd,cde,rfg,count(*),bcd,cde,rfg,count(*),bcd,cde,rfg,count(*) ;

if some one written, then newer or code reader understand easily
select abcd,
   cde,
   rfg,
   count(*),
...,
..,
...,
like line by line

in postgres direct option format is not available.i want see code
intended proper.
in context editor i didn't find format option only like  lower to
upper..




http://sqlformat.darold.net/

To install locally:
https://github.com/darold/pgFormatter

http://format-sql.de/

To install locally:
https://github.com/paetzke/format-sql




On Mon, Sep 28, 2015 at 11:20 PM, David G. Johnston
> wrote:

CREATE FUNCTION
CREATE VIEW

As yes, I am being mostly serious - though I have been pondering
seeing what tools can do as opposed to the manual formatting
I've been performing.  Even a basic linter would be helpful...

The big problem is you need to define what it means to be
beautiful.  Understandable is a totally different area and that
is more where views and functions come in so you can provide
names to the various constructs you are using.  CTE/WITH
facilitate this as well.

David J.


On Mon, Sep 28, 2015 at 8:45 AM, Ramesh T
> wrote:

Hi All,
   How to change sql format to look beautiful and
understandable using pgadmin3 or else ther tools for postgres.

any help appreciated..







--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format

[Ramesh T]

Nice, thank you.

On Tue, Sep 29, 2015 at 11:16 PM, Adrian Klaver 
wrote:

> On 09/29/2015 06:13 AM, Ramesh T wrote:
>
>>
>>
>> On Tue, Sep 29, 2015 at 6:43 PM, Ramesh T > > wrote:
>>
>> in my mind to be beautiful ,avoid confusion to understand sql query
>> code
>>
>> like
>>
>> select
>> abcd,cde,rfg,count(*),bcd,cde,rfg,count(*),bcd,cde,rfg,count(*) ;
>>
>> if some one written, then newer or code reader understand easily
>> select abcd,
>>cde,
>>rfg,
>>count(*),
>> ...,
>> ..,
>> ...,
>> like line by line
>>
>> in postgres direct option format is not available.i want see code
>> intended proper.
>> in context editor i didn't find format option only like  lower to
>> upper..
>>
>>
>
> http://sqlformat.darold.net/
>
> To install locally:
> https://github.com/darold/pgFormatter
>
> http://format-sql.de/
>
> To install locally:
> https://github.com/paetzke/format-sql
>
>
>>
>> On Mon, Sep 28, 2015 at 11:20 PM, David G. Johnston
>> >
>> wrote:
>>
>> CREATE FUNCTION
>> CREATE VIEW
>>
>> As yes, I am being mostly serious - though I have been pondering
>> seeing what tools can do as opposed to the manual formatting
>> I've been performing.  Even a basic linter would be helpful...
>>
>> The big problem is you need to define what it means to be
>> beautiful.  Understandable is a totally different area and that
>> is more where views and functions come in so you can provide
>> names to the various constructs you are using.  CTE/WITH
>> facilitate this as well.
>>
>> David J.
>>
>>
>> On Mon, Sep 28, 2015 at 8:45 AM, Ramesh T
>> > > wrote:
>>
>> Hi All,
>>How to change sql format to look beautiful and
>> understandable using pgadmin3 or else ther tools for postgres.
>>
>> any help appreciated..
>>
>>
>>
>>
>>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>

Re: [GENERAL] Format

[David G. Johnston]

On Mon, Sep 28, 2015 at 1:59 PM, Igor Neyman  wrote:

> Hi All,
>
>   How to change sql format to look beautiful and understandable
> using pgadmin3 or else ther tools for postgres.
>
>
>
> any help appreciated..
>
>
>
>
>
> Are you looking for SQL editor?
>
> If that’s the case, take a look at contexteditor.org
>
>
>
​format => alter; all I see in the linked editor is highlighting.​..

David J.

Re: [GENERAL] Format

[David G. Johnston]

CREATE FUNCTION
CREATE VIEW

As yes, I am being mostly serious - though I have been pondering seeing
what tools can do as opposed to the manual formatting I've been
performing.  Even a basic linter would be helpful...

The big problem is you need to define what it means to be beautiful.
Understandable is a totally different area and that is more where views and
functions come in so you can provide names to the various constructs you
are using.  CTE/WITH facilitate this as well.

David J.


On Mon, Sep 28, 2015 at 8:45 AM, Ramesh T 
wrote:

> Hi All,
>   How to change sql format to look beautiful and understandable
> using pgadmin3 or else ther tools for postgres.
>
> any help appreciated..
>

Re: [GENERAL] Format

[Igor Neyman]

From: David G. Johnston [mailto:david.g.johns...@gmail.com]
Sent: Monday, September 28, 2015 3:14 PM
To: Igor Neyman <iney...@perceptron.com>
Cc: Ramesh T <rameshparnandit...@gmail.com>; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Format

On Mon, Sep 28, 2015 at 1:59 PM, Igor Neyman 
<iney...@perceptron.com<mailto:iney...@perceptron.com>> wrote:
Hi All,
  How to change sql format to look beautiful and understandable using 
pgadmin3 or else ther tools for postgres.

any help appreciated..


Are you looking for SQL editor?
If that’s the case, take a look at contexteditor.org<http://contexteditor.org>


​format => alter; all I see in the linked editor is highlighting.​..

David J.

Not only, there is little of formatting, like TABs.
But, even highlighting helps.

Regards,
Igor Neyman

Re: [GENERAL] Format

[Igor Neyman]

Hi All,
  How to change sql format to look beautiful and understandable using 
pgadmin3 or else ther tools for postgres.

any help appreciated..


Are you looking for SQL editor?
If that’s the case, take a look at contexteditor.org

Regards,
Igor Neyman

Re: [GENERAL] Format

[David G. Johnston]

>
>
> Not only, there is little of formatting, like TABs.
>
> But, even highlighting helps.
>
>
>
​Since pgAdminIII does highlighting I figured the OP wanted something
more...I know what I am looking is more than just highlighting.

David J.
​

Re: [GENERAL] Format of Pioint datatype.... lat/long or long/lat??

[Adrian Klaver]

On 12/31/2013 12:45 PM, peterlen wrote:

PostgreSQL has a geometric data type of point.  The format is listed as (x,
y) but I am not sure if the X is to represent latitude or longitude.  I have
seen different systems that us X for either.  Typically, coordinates should
be read as lat/long but I have seen the opposite as well.  An example in the
help docs listed a point coordinate as x= longitude and y=latitude.  Can
someone clarify what the postgres standard is?  What this will come down to
is how built-in geospatial functions will interpret the point value.


Well the point data type is just that a point with x, y coordinates. The 
concept of longitude and latitude are higher order defined other systems 
that use the point type as a building block, i.e. Postgis. So which help 
docs did you see the x= longitude and y=latitude statement?




Thanks - Peter



--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Format-of-Pioint-datatype-lat-long-or-long-lat-tp5784939.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.





--
Adrian Klaver
adrian.kla...@gmail.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format of Pioint datatype.... lat/long or long/lat??

[John R Pierce]

On 12/31/2013 12:45 PM, peterlen wrote:

PostgreSQL has a geometric data type of point.  The format is listed as (x,
y) but I am not sure if the X is to represent latitude or longitude.  I have
seen different systems that us X for either.  Typically, coordinates should
be read as lat/long but I have seen the opposite as well.  An example in the
help docs listed a point coordinate as x= longitude and y=latitude.  Can
someone clarify what the postgres standard is?  What this will come down to
is how built-in geospatial functions will interpret the point value.



point is just x,y, it doesn't understand the spherical lat/long math 
(unless you install PostGIS and use its Geometry types which are fully 
aware of spherical coords), that said, Latitude is generally used as X 
(left/right, aka east/west), while Longitude is Y (up/down aka north/south)






--
john r pierce  37N 122W
somewhere on the middle of the left coast



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format of Pioint datatype.... lat/long or long/lat??

[peterlen]

Adrian - Thanks for the reply.  The example was from
http://www.postgresql.org/docs/9.1/static/tutorial-populate.html with the
example of:

INSERT INTO cities VALUES ('San Francisco', '(-194.0, 53.0)');

That is not a valid coordinate but it is clear that they are trying to
declare it as longitude (-194) for x and latitude (53) for y.  Yes, I would
understand that it is up to other GIS clients to interpret those values as
coordinates but they would need to know which value is which (lat or long). 
In the case above it would be easy to identify any value over 90 as being a
longitude value but what if the values were listed as 10,40.  That would
represent two completely different points on the map if it were interpreted
as lat/long compared to long/lat.  This is why I was asking the question.  



--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Format-of-Pioint-datatype-lat-long-or-long-lat-tp5784939p5784953.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format of Pioint datatype.... lat/long or long/lat??

[peterlen]

John - Appreciate the response.  The reason why I asked this question is
specifically for operations within PostGIS that will utilize the point
values and so it is pretty important that the point values are entered
correctly.  Your description of X representing east/west and Y representing
north/south is exactly why this is such a confusing issue because an
east/west coordinate value is a longitude value while north/south is a
latitude value so X can't represent an longitude value representing
east/west.  In the example I cited, it listed the X value as -194.  While
that value is invalid it is supposed to represent the longitude value.  In
one sense, I can see X representing latitude if you see X as the horizontal
plane and Y as the vertical plane because latitude rings are horizontal and
longitude rings are vertical, and again, this is why this can get confusing
because people will interpret things differently.  Part of this confusion
with X vs Y stems from some of the JavaScript mapping APIs (like Google Maps
and OpenLayers) where one API will list X as a latitude and the other will
list X as a longitude.



--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Format-of-Pioint-datatype-lat-long-or-long-lat-tp5784939p5784954.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format of Pioint datatype.... lat/long or long/lat??

[Adrian Klaver]

On 12/31/2013 01:09 PM, John R Pierce wrote:

On 12/31/2013 12:45 PM, peterlen wrote:

PostgreSQL has a geometric data type of point.  The format is listed
as (x,
y) but I am not sure if the X is to represent latitude or longitude.
I have
seen different systems that us X for either.  Typically, coordinates
should
be read as lat/long but I have seen the opposite as well.  An example
in the
help docs listed a point coordinate as x= longitude and y=latitude.  Can
someone clarify what the postgres standard is?  What this will come
down to
is how built-in geospatial functions will interpret the point value.



point is just x,y, it doesn't understand the spherical lat/long math
(unless you install PostGIS and use its Geometry types which are fully
aware of spherical coords), that said, Latitude is generally used as X
(left/right, aka east/west), while Longitude is Y (up/down aka north/south)


I thought it was the other way around?










--
Adrian Klaver
adrian.kla...@gmail.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format of Pioint datatype.... lat/long or long/lat??

[Adrian Klaver]

On 12/31/2013 02:16 PM, peterlen wrote:

Adrian - Thanks for the reply.  The example was from
http://www.postgresql.org/docs/9.1/static/tutorial-populate.html with the
example of:

INSERT INTO cities VALUES ('San Francisco', '(-194.0, 53.0)');

That is not a valid coordinate but it is clear that they are trying to
declare it as longitude (-194) for x and latitude (53) for y.  Yes, I would
understand that it is up to other GIS clients to interpret those values as
coordinates but they would need to know which value is which (lat or long).
In the case above it would be easy to identify any value over 90 as being a
longitude value but what if the values were listed as 10,40.  That would
represent two completely different points on the map if it were interpreted
as lat/long compared to long/lat.  This is why I was asking the question.


One of those things that is best verified for a particular situation. 
For Postgis see here:


http://postgis.org/docs/ST_MakePoint.html

'Note x is longitude and y is latitude'





--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Format-of-Pioint-datatype-lat-long-or-long-lat-tp5784939p5784953.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.





--
Adrian Klaver
adrian.kla...@gmail.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format of Pioint datatype.... lat/long or long/lat??

[peterlen]

Perfect.  That answers it.  Thanks for providing that link.



--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Format-of-Pioint-datatype-lat-long-or-long-lat-tp5784939p5784960.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format of Pioint datatype.... lat/long or long/lat??

[John R Pierce]

On 12/31/2013 2:34 PM, Adrian Klaver wrote:

point is just x,y, it doesn't understand the spherical lat/long math
(unless you install PostGIS and use its Geometry types which are fully
aware of spherical coords), that said, Latitude is generally used as X
(left/right, aka east/west), while Longitude is Y (up/down aka 
north/south)


I thought it was the other way around? 



arrrgh, you're right.   LONGITUDE is east/west, LATITUDE Is 
north/south.  so, its X = long, Y = lat.


doy!

sittin here at 37N


--
john r pierce  37N 122W
somewhere on the middle of the left coast



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format of Pioint datatype.... lat/long or long/lat??

[Adrian Klaver]

On 12/31/2013 03:06 PM, John R Pierce wrote:

On 12/31/2013 2:34 PM, Adrian Klaver wrote:

point is just x,y, it doesn't understand the spherical lat/long math
(unless you install PostGIS and use its Geometry types which are fully
aware of spherical coords), that said, Latitude is generally used as X
(left/right, aka east/west), while Longitude is Y (up/down aka
north/south)


I thought it was the other way around?



arrrgh, you're right.   LONGITUDE is east/west, LATITUDE Is
north/south.  so, its X = long, Y = lat.

doy!


Yea, it is one of those inverse things, longitudinal lines run in a N-S 
direction but are plotted in the E-W direction and vice versa for 
latitude. Me remembering usually involves a certain amount of hand 
waving while I work it out on an imaginary globe:)




sittin here at 37N





--
Adrian Klaver
adrian.kla...@gmail.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format string for ISO-8601 date and time

[Pavel Stehule]

Hello

2009/2/26 Daniel Verite dan...@manitou-mail.org:
 Hi,

 Is there a format string for to_char(timestamptz, text) that would output a
 timestamp in full ISO-8601 format? That is, something like
 1977-04-22T01:00:00-05:00

 I can't find a way to extract the offset against GMT from the docs here:
 http://www.postgresql.org/docs/8.3/static/functions-formatting.html

 If not, what would be the way to convert a timestamp to such a string
 regardless of the session's datestyle settings?

try to look on function extract, there you can get timezone from any
timestamp with time zone.

regards
Pavel Stehule

 Thanks,

 --
 Daniel

 --
 Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-general


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format string for ISO-8601 date and time

[Sam Mason]

On Thu, Feb 26, 2009 at 10:50:18AM +0100, Daniel Verite wrote:
 Is there a format string for to_char(timestamptz, text) that would 
 output a timestamp in full ISO-8601 format? That is, something like 
 1977-04-22T01:00:00-05:00

If I'm understanding correctly, that's a bit awkward to do.  PG only
ever records timestamps as an instant in time and throws away any
timezone information as soon as it can (i.e. as soon as it's been
parsed).  The difference between a timestamp with a timezone and without
is as follows:

  1) values of type timestamp with time zone are always converted
  to UTC (either using the timezone specified or using the session's
  current timezone value) and then when they're sent back to the value
  is then corrected to the session's timezone (or an explicit AT TIME
  ZONE can be specified).

  2) values of type timestamp without time zone (or alternatively
  spelled just timestamp) ignore any timezone specified and assume the
  value is UTC.

I find it all quite confusing (and hence the above may be wrong) but
have the luxury of ignoring it as all as my users are in the same
timezone.  That said, it's a useful set of abstractions as lots of
people use them regularly.

I'd recommend a read through the docs at:

  http://www.postgresql.org/docs/current/static/datatype-datetime.html

-- 
  Sam  http://samason.me.uk/

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format string for ISO-8601 date and time

[Daniel Verite]

Pavel Stehule wrote:

 Is there a format string for to_char(timestamptz, text) that would 

output a

 timestamp in full ISO-8601 format? That is, something like
 1977-04-22T01:00:00-05:00

 I can't find a way to extract the offset against GMT from the docs 

here:

 http://www.postgresql.org/docs/8.3/static/functions-formatting.html

 If not, what would be the way to convert a timestamp to such a 

string

 regardless of the session's datestyle settings?

try to look on function extract, there you can get timezone from any
timestamp with time zone.


Thanks, I've come up with this expression, then:

to_char(date, '-MM-DD')
|| 'T'
|| to_char(date, 'HH24:MI:SS')
|| to_char(extract('timezone_hour' from date),'S00')
||':'
|| to_char(extract('timezone_minute' from date),'FM00')

This form is typically used in datetime fields in xml files, and 
somehow I was expecting a pre-existing format for it, such as php5's 
date(c) rather than the complex expression above :)


Best regards,

--
Daniel

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format string for ISO-8601 date and time

[Daniel Verite]

Sam Mason wrote:


  1) values of type timestamp with time zone are always converted
  to UTC (either using the timezone specified or using the session's
  current timezone value) and then when they're sent back to the 

value

  is then corrected to the session's timezone (or an explicit AT TIME
  ZONE can be specified).

  2) values of type timestamp without time zone (or alternatively
  spelled just timestamp) ignore any timezone specified and assume 

the

  value is UTC.

I find it all quite confusing (and hence the above may be wrong) but
have the luxury of ignoring it as all as my users are in the same
timezone.  That said, it's a useful set of abstractions as lots of
people use them regularly.


Thanks, I was aware already that timestamp with time zone doesn't 
store any timezone contrary to what its name seems to imply. (Though 
when I first started with PG some years ago, I sure fell in that trap)


Best regards,

--
Daniel

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Format Float numbers

[A. Kretschmer]

am  Thu, dem 10.01.2008, um 10:03:05 -0300 mailte Fernando Xavier folgendes:
 Hi,
 
 I want format a column in select result:
 
 1.1 = 1.10
 
 Any idea?

Yes. You can use to_char() or a CAST like


test=*# select 1.1::numeric(10,2);
 numeric
-
1.10
(1 row)


Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: - Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [GENERAL] Format Float numbers

[Albe Laurenz]

 I want format a column in select result:
 
 1.1 = 1.10
 
 Any idea?

Try the to_date() function like

SELECT to_char(1.1, '0.99');

Yours,
Laurenz Albe

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

RE: [GENERAL] Format of BOOLEAN

[Nicolas Huillard]

 -Message d'origine-
 De:   Lehmeier, Michael [SMTP:[EMAIL PROTECTED]]
 Date: jeudi 7 juin 2001 18:06
 Objet:[GENERAL] Format of BOOLEAN
 
 testdb=# SELECT * FROM testtable WHERE acolumn = t;
 ERROR:  Attribute 't' not found

testdb=# SELECT * FROM testtable WHERE acolumn = 't';

Don't forget the single quote around the t : a boolean is a single char...

NH

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [GENERAL] Format of BOOLEAN

[Thalis A. Kalfigopoulos]

On Thu, 7 Jun 2001, Lehmeier, Michael wrote:

 Hello
 
 When I SELECT a row with a BOOLEAN in it I get either 't' or 'f'.
 But when I use this same value in the WHERE condition I get an error,
 because PostgreSQL demands either 'true' or 'false'.
 
 Example:
 
 testdb=# create table testtable (acolumn BOOLEAN);
 CREATE
 testdb=# INSERT INTO testtable VALUES (true);
 INSERT 161246 1
 testdb=# SELECT * FROM testtable;
  acolumn 
 -
  t
 (1 row)
  
 testdb=# SELECT * FROM testtable WHERE acolumn = t;
 ERROR:  Attribute 't' not found
 
 This is a real problem for me since I am currently writing on a mostly
 database independent engine. PostgreSQL would be the the first time that
 I can't write into a database what I read from it.

you mean read from a db what you wrote into it

 
 Is it possible to change the settings of PostgreSQL somewhere so that
 I get 'true' or 'false'?
 
 Thank you!

You have to give

SELECT * FROM testtable WHERE col='t';[single quote the value]

It also works with WHERE col='true';


cheers,
thalis


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster