If you have an actual business-logic requirement to restrict a field to
no more than N characters, then by all means use varchar(N); that's
what it's for. But I agree with what I think Josh meant: there is very
seldom any non-broken reason to have a hard upper limit on string
lengths. If you thin
> Frankly, the only reason to use anything other than TEXT is
> compatibility with other databases and applications.
The main reason why I am still using VARCHAR rather than TEXT in many
places is to ensure that the column can be indexed. Postgres, it seems,
refuses to insert a string that is long
On Sat, Mar 06, 2004 at 02:17:35PM +0100, Eric Jain wrote:
> places is to ensure that the column can be indexed. Postgres, it seems,
> refuses to insert a string that is longer than some value into an
> indexed column, and I'll rather have such errors flagged while inserting
Care to provide some d
On 3/3/04 6:53 PM, Tom Lane wrote:
> John Siracusa <[EMAIL PROTECTED]> writes:
>> Given an index like this:
>> CREATE UNIQUE INDEX i1 ON t1 (c1) WHERE c1 IS NOT NULL;
>> and a query like this:
>> SELECT * FROM t1 WHERE c1 = 123;
>> I'd like the planner to be smart enough to use an index sca
"Eric Jain" <[EMAIL PROTECTED]> writes:
> The main reason why I am still using VARCHAR rather than TEXT in many
> places is to ensure that the column can be indexed. Postgres, it seems,
> refuses to insert a string that is longer than some value into an
> indexed column, and I'll rather have such e
John Siracusa <[EMAIL PROTECTED]> writes:
> So apparently all I can do is find out if it's a null test, but not if it is
> specifically "IS NOT NULL"
No, because once you have determined that the node really IsA NullTest,
you can cast the pointer to (NullTest *) and look at the
NullTest-specific f
> Actually, I don't. Good reason to have a check constraint on it though
> (hint, check constraints can be changed while column types cannot be, at
> this moment).
Is there a way to copy a table INCLUDING the check constraints? If not,
then that information is lost, unlike varchar(n).
--
Mike Nol
On Sat, 2004-03-06 at 20:16, Mike Nolan wrote:
> > Actually, I don't. Good reason to have a check constraint on it though
> > (hint, check constraints can be changed while column types cannot be, at
> > this moment).
>
> Is there a way to copy a table INCLUDING the check constraints? If not,
> th
Mike Nolan wrote:
Is there a way to copy a table INCLUDING the check constraints? If not,
then that information is lost, unlike varchar(n).
"pg_dump -t" should work fine, unless I'm misunderstanding you.
-Neil
---(end of broadcast)---
TIP 5: Have y
> Mike Nolan wrote:
> > Is there a way to copy a table INCLUDING the check constraints? If not,
> > then that information is lost, unlike varchar(n).
>
> "pg_dump -t" should work fine, unless I'm misunderstanding you.
I was specifically referring to doing it in SQL.
The COPY command goes from
On 3/3/04 6:53 PM, Tom Lane wrote:
John Siracusa <[EMAIL PROTECTED]> writes:
Given an index like this:
CREATE UNIQUE INDEX i1 ON t1 (c1) WHERE c1 IS NOT NULL;
and a query like this:
SELECT * FROM t1 WHERE c1 = 123;
I'd like the planner to be smart enough to use an index scan using
i1
--On Saturday, March 06, 2004 21:29:27 -0500 John Siracusa
<[EMAIL PROTECTED]> wrote:
On 3/3/04 6:53 PM, Tom Lane wrote:
John Siracusa <[EMAIL PROTECTED]> writes:
Given an index like this:
CREATE UNIQUE INDEX i1 ON t1 (c1) WHERE c1 IS NOT NULL;
and a query like this:
SELECT * FROM
On Sat, 2004-03-06 at 21:26, Mike Nolan wrote:
> > Mike Nolan wrote:
> > > Is there a way to copy a table INCLUDING the check constraints? If not,
> > > then that information is lost, unlike varchar(n).
> >
> > "pg_dump -t" should work fine, unless I'm misunderstanding you.
>
> I was specificall
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Just a suggestion, please use diff -c format, as it makes it easier for
> the folks who apply the patches to do so.
That's not just a suggestion ... patches that aren't in diff -c (or at
least diff -u) format will be rejected out of hand. Without the c
14 matches
Mail list logo
