On Thu, Feb 24, 2011 at 1:10 AM, Michael Glaesemann wrote:
>
> On Feb 23, 2011, at 13:49, John R Pierce wrote:
>
> > On 02/23/11 4:44 AM, Stephane Bortzmeyer wrote:
> >>> *3. Start-End IP format :* 1.2.3.0-1.2.3.255
> >> You don't even need to program the conversion, it is already done:
> >>
On Thu, Feb 24, 2011 at 3:03 AM, Tom Lane wrote:
> John R Pierce writes:
> > On 02/23/11 4:44 AM, Stephane Bortzmeyer wrote:
> > *3. Start-End IP format :* 1.2.3.0-1.2.3.255
> >> You don't even need to program the conversion, it is already done:
> >>
> >> % netmask 1.2.3.0:1.2.3.255
> >> 1.
On 02/23/11 1:33 PM, Tom Lane wrote:
The question is does he actually have a use-case for address ranges that
don't correspond to legal CIDR ranges, but do nonetheless have an
identifiable lower boundary, upper boundary, and no holes? And if so,
what is it? The whole thing looked to me like som
John R Pierce writes:
> On 02/23/11 4:44 AM, Stephane Bortzmeyer wrote:
> *3. Start-End IP format :* 1.2.3.0-1.2.3.255
>> You don't even need to program the conversion, it is already done:
>>
>> % netmask 1.2.3.0:1.2.3.255
>> 1.2.3.0/24
> yes, but what about 10.1.2.57-10.1.2.123 ?presum
On Feb 23, 2011, at 13:49, John R Pierce wrote:
> On 02/23/11 4:44 AM, Stephane Bortzmeyer wrote:
>>> *3. Start-End IP format :* 1.2.3.0-1.2.3.255
>> You don't even need to program the conversion, it is already done:
>>
>> % netmask 1.2.3.0:1.2.3.255
>> 1.2.3.0/24
>
> yes, but what
On 02/23/11 4:44 AM, Stephane Bortzmeyer wrote:
*3. Start-End IP format :* 1.2.3.0-1.2.3.255
You don't even need to program the conversion, it is already done:
% netmask 1.2.3.0:1.2.3.255
1.2.3.0/24
yes, but what about 10.1.2.57-10.1.2.123 ?presumably valid in his
range sys
On Wed, Feb 23, 2011 at 05:39:26PM +0530,
Gaini Rajeshwar wrote
a message of 52 lines which said:
> I wanted to store ip addresses in table. I wanted to support the following 3
> types of ip addresses.
>
> *1. Wildcard format :* 1.2.3.*
> *
> *
> *2. CIDR format:* 1.2.
On Wed, Feb 23, 2011 at 02:30:18PM +0200,
Sim Zacks wrote
a message of 97 lines which said:
> a regular varchar or text field.
Very bad idea since they don't support canonicalization (2001:db8::1
== 2001:db8:0:0:0:0:0:1) or masking (set_masklen(address, 20)).
--
Sent via pgsql-general maili
a regular varchar or text field.
On 02/23/2011 02:09 PM, Gaini Rajeshwar wrote:
Hi All,
I wanted to store ip addresses in table. I wanted to support the
following 3 types of ip addresses.
|*1. Wildcard format :* 1.2.3.*
*
*|
|*2. CIDR format:* 1.2.3/24 OR 1.2.3.4/2
Hi All,
I wanted to store ip addresses in table. I wanted to support the following 3
types of ip addresses.
*1. Wildcard format :* 1.2.3.*
*
*
*2. CIDR format:* 1.2.3/24 OR 1.2.3.4/255.255.255.0
*
*
*3. Start-End IP format :* 1.2.3.0-1.2.3.255
I had a look at CIDR
PROTECTED]
Sent: Mon, 23 Jun 2008 15:00:05 -0400
Subject: Re: [GENERAL] Data Types
"Roberts, Jon" <[EMAIL PROTECTED]> writes:
> Character will use more disk space than varchar so it does make a
> difference.
char also has very peculiar comparison semantics. Unl
"Roberts, Jon" <[EMAIL PROTECTED]> writes:
> Character will use more disk space than varchar so it does make a
> difference.
char also has very peculiar comparison semantics. Unless your strings
are really truly fixed-length, you should just about always use varchar.
rega
and text values.
Jon
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Gould
Sent: Monday, June 23, 2008 1:01 PM
To: pgsql-general General
Subject: [GENERAL] Data Types
We are converting our system from using Sybase'
We are converting our system from using Sybase's SQL Anywhere 10 to PostGres
8.3. In SQL Anywhere there technically isn't any difference in how a char and
varchar is stored. They are all an array of char[1]. So we always just defined
everything as a char since right truncation is the default.
Thank you gentlemen, this will keep me busy for a while.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James Cradock
Sent: Friday, December 30, 2005 1:05 PM
To: Jonel Rienton
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Data types
Try
Try pg_type. typname should give you what you're looking for.
On Dec 30, 2005, at 1:57 PM, Jonel Rienton wrote:
Hi guys,
Does Postgres store all the possible column datatypes somewhere in its
system tables? Like int8, int4, character varying, etc. I'm trying
to write
another GUI client tha
On Fri, Dec 30, 2005 at 12:57:57PM -0600, Jonel Rienton wrote:
> Does Postgres store all the possible column datatypes somewhere in its
> system tables? Like int8, int4, character varying, etc. I'm trying to write
> another GUI client that can list all the database objects in Postgres.
See "Syste
Hi guys,
Does Postgres store all the possible column datatypes somewhere in its
system tables? Like int8, int4, character varying, etc. I'm trying to write
another GUI client that can list all the database objects in Postgres.
Thanks.
Regards,
Jonel
--
I know not english well, but I know 9 co
Title: RE: [GENERAL] Data types?
I thought:
\dT
This should do it
Ben
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 08 March 2001 01:00
> To: Christopher Sawtell
> Cc: Flemming Frøkjær; [EMAIL PROTECTED]
> Subject: Re: [G
Christopher Sawtell <[EMAIL PROTECTED]> writes:
> On Thu, 08 Mar 2001 12:29, Flemming Frøkjær wrote:
>> How do i find out what data types are available in PostgreSQL.
> Look in the regression tests. Interesting stuff.
And there's always "select * from pg_type" ... not to mention the source
code
On Thu, 08 Mar 2001 12:29, Flemming Frøkjær wrote:
> How do i find out what data types are available in PostgreSQL.
> I know there are more that the ones in the docs, and i ones saw a
> command to list all the data types. And there was a lot more than the
> ones from the docs.
Look in the regress
How do i find out what data types are available in PostgreSQL.
I know there are more that the ones in the docs, and i ones saw a command
to list all the data types. And there was a lot more than the ones from the
docs.
\Flemming
---(end of broadcast)-
22 matches
Mail list logo
