head	1.4;
access;
symbols
	REL7_4_29:1.3
	REL7_4_28:1.3
	REL7_4_27:1.3
	REL7_4_26:1.3
	REL7_4_25:1.3
	REL7_4_24:1.3
	REL7_4_23:1.3
	REL7_4_22:1.3
	REL7_4_21:1.3
	REL7_4_20:1.3
	REL7_3_21:1.3
	REL7_4_19:1.3
	REL7_3_20:1.3
	REL7_4_18:1.3
	REL7_3_19:1.3
	REL7_4_17:1.3
	REL7_3_18:1.3
	REL7_4_16:1.3
	REL7_4_15:1.3
	REL7_3_17:1.3
	REL7_4_14:1.3
	REL7_3_16:1.3
	REL7_3_15:1.3
	REL7_4_13:1.3
	REL7_3_14:1.3
	REL7_4_12:1.3
	REL7_3_13:1.3
	REL7_4_11:1.3
	REL7_3_12:1.3
	REL7_4_10:1.3
	REL7_3_11:1.3
	REL7_4_9:1.3
	REL7_2_8:1.3
	REL7_3_10:1.3
	REL7_4_8:1.3
	REL7_2_7:1.3
	REL7_3_9:1.3
	REL7_4_7:1.3
	REL8_0_0BETA4:1.3
	REL7_4_6:1.3
	REL7_3_8:1.3
	REL7_2_6:1.3
	REL8_0_0BETA3:1.3
	REL8_0_0BETA2:1.3
	REL7_2_5:1.3
	REL7_4_5:1.3
	REL7_3_7:1.3
	REL7_4_4:1.3
	REL8_0_0BETA1:1.3
	REL7_4_3:1.3
	REL7_4_2:1.3
	REL7_3_6:1.3
	REL7_4_1:1.3
	REL7_3_5:1.3
	REL7_4:1.3
	REL7_4_RC2:1.3
	REL7_4_STABLE:1.3.0.8
	REL7_4_RC1:1.3
	REL7_4_BETA5:1.3
	REL7_4_BETA4:1.3
	REL7_4_BETA3:1.3
	REL7_4_BETA2:1.3
	WIN32_DEV:1.3.0.6
	REL7_4_BETA1:1.3
	REL7_3_4:1.3
	REL7_3_2:1.3
	REL7_2_4:1.3
	REL7_3_STABLE:1.3.0.4
	REL7_2_3:1.3
	REL7_2_STABLE:1.3.0.2
	REL7_2:1.3
	REL7_2_RC2:1.3
	REL7_2_RC1:1.3
	REL7_2_BETA5:1.3
	REL7_2_BETA4:1.3
	REL7_2_BETA3:1.1
	REL7_2_BETA2:1.1
	REL7_2_BETA1:1.1
	REL7_1_2:1.1
	REL7_1_STABLE:1.1.0.4
	REL7_1_BETA:1.1
	REL7_1_BETA3:1.1
	REL7_1_BETA2:1.1
	REL7_1:1.1
	REL7_0_PATCHES:1.1.0.2
	REL7_0:1.1;
locks; strict;
comment	@# @;


1.4
date	2004.11.08.15.19.31;	author momjian;	state dead;
branches;
next	1.3;

1.3
date	2001.12.05.21.07.23;	author momjian;	state Exp;
branches;
next	1.2;

1.2
date	2001.11.27.20.25.45;	author momjian;	state dead;
branches;
next	1.1;

1.1
date	99.09.21.19.58.00;	author momjian;	state Exp;
branches;
next	;


desc
@@


1.4
log
@Remove atttypmod TODO.detail and merge into TODO list.
@
text
@From tgl@@sss.pgh.pa.us Wed Nov 21 22:51:02 2001
Return-path: <tgl@@sss.pgh.pa.us>
Received: from sss.pgh.pa.us (root@@[192.204.191.242])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAM3p2v12831
	for <pgman@@candle.pha.pa.us>; Wed, 21 Nov 2001 22:51:02 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id fAM3p4c27978;
	Wed, 21 Nov 2001 22:51:04 -0500 (EST)
To: Bruce Momjian <pgman@@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@@gmx.net>,
   PostgreSQL Development <pgsql-hackers@@postgresql.org>,
   stiening@@cannon.astro.umass.edu, pgsql-bugs@@postgresql.org
Subject: Re: [BUGS] Bug #513: union all changes char(3) column definition 
In-Reply-To: <200111220310.fAM3A2V08766@@candle.pha.pa.us> 
References: <200111220310.fAM3A2V08766@@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@@candle.pha.pa.us>
	message dated "Wed, 21 Nov 2001 22:10:02 -0500"
Date: Wed, 21 Nov 2001 22:51:04 -0500
Message-ID: <27975.1006401064@@sss.pgh.pa.us>
From: Tom Lane <tgl@@sss.pgh.pa.us>
Status: ORr

Bruce Momjian <pgman@@candle.pha.pa.us> writes:
> Added to TODO:
> 	* CREATE TABLE AS can not determine column lengths from expressions
> Seems it should be documented.  Do we throw an error in these cases?

No.  What we do right now is to generate non-length-constrained column
types for the created table.

Your TODO item is too pessimistic: we *do* determine the column length
in simple cases.  For example:

regression=# create table foo (f1 char(3));
CREATE
regression=# create table bar as select * from foo;
SELECT
regression=# \d bar
            Table "bar"
 Column |     Type     | Modifiers
--------+--------------+-----------
 f1     | character(3) |

However, in more complex cases we don't know the column length:

regression=# create table baz as select f1 || 'z' as f1 from foo;
SELECT
regression=# \d baz
         Table "baz"
 Column |  Type  | Modifiers
--------+--------+-----------
 f1     | bpchar |

The argument here is about how much intelligence it's reasonable to
expect the system to have.  It's very clearly not feasible to derive
a length limit automagically in every case.  How hard should we try?

			regards, tom lane

From pgsql-bugs-owner+M2695=candle.pha.pa.us=pgman@@postgresql.org Wed Nov 21 23:16:19 2001
Return-path: <pgsql-bugs-owner+M2695=candle.pha.pa.us=pgman@@postgresql.org>
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAM4GJv15505
	for <pgman@@candle.pha.pa.us>; Wed, 21 Nov 2001 23:16:19 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fAM4CxN38340
	for <pgman@@candle.pha.pa.us>; Wed, 21 Nov 2001 22:12:59 -0600 (CST)
	(envelope-from pgsql-bugs-owner+M2695=candle.pha.pa.us=pgman@@postgresql.org)
Received: from sss.pgh.pa.us ([192.204.191.242])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fAM48em84313;
	Wed, 21 Nov 2001 23:08:40 -0500 (EST)
	(envelope-from tgl@@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id fAM48bc28082;
	Wed, 21 Nov 2001 23:08:37 -0500 (EST)
To: Bruce Momjian <pgman@@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@@gmx.net>,
   PostgreSQL Development <pgsql-hackers@@postgresql.org>,
   stiening@@cannon.astro.umass.edu, pgsql-bugs@@postgresql.org
Subject: Re: [BUGS] Bug #513: union all changes char(3) column definition 
In-Reply-To: <200111220353.fAM3rRg12994@@candle.pha.pa.us> 
References: <200111220353.fAM3rRg12994@@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@@candle.pha.pa.us>
	message dated "Wed, 21 Nov 2001 22:53:27 -0500"
Date: Wed, 21 Nov 2001 23:08:37 -0500
Message-ID: <28079.1006402117@@sss.pgh.pa.us>
From: Tom Lane <tgl@@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@@postgresql.org
Status: OR

Bruce Momjian <pgman@@candle.pha.pa.us> writes:
> However, I don't think creating a bpchar
> with no length is a proper solution.  Should we just punt to text in
> these cases?

How many special cases like that do you want to put into the allegedly
datatype-independent CREATE TABLE code?

If I thought this were the only case then I'd not object ... but it
looks like a slippery slope from here.

And --- it's not like replacing "bpchar" with "text" actually buys us
any useful new functionality.  AFAICS it's just a cosmetic thing.

			regards, tom lane

PS: On the other hand, we might consider attacking the problem from
the reverse direction, ie *removing* code.  For example, if there
weren't redundant || operators for char and varchar, then every ||
operation would yield text, and the example we're looking at would
work the way you want for free.  I've thought for awhile that we
could use a pass through pg_proc and pg_operator to remove some
entries we don't really need.

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

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

From tgl@@sss.pgh.pa.us Wed Nov 21 23:08:36 2001
Return-path: <tgl@@sss.pgh.pa.us>
Received: from sss.pgh.pa.us (root@@[192.204.191.242])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAM48av14412
	for <pgman@@candle.pha.pa.us>; Wed, 21 Nov 2001 23:08:36 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id fAM48bc28082;
	Wed, 21 Nov 2001 23:08:37 -0500 (EST)
To: Bruce Momjian <pgman@@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@@gmx.net>,
   PostgreSQL Development <pgsql-hackers@@postgresql.org>,
   stiening@@cannon.astro.umass.edu, pgsql-bugs@@postgresql.org
Subject: Re: [BUGS] Bug #513: union all changes char(3) column definition 
In-Reply-To: <200111220353.fAM3rRg12994@@candle.pha.pa.us> 
References: <200111220353.fAM3rRg12994@@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@@candle.pha.pa.us>
	message dated "Wed, 21 Nov 2001 22:53:27 -0500"
Date: Wed, 21 Nov 2001 23:08:37 -0500
Message-ID: <28079.1006402117@@sss.pgh.pa.us>
From: Tom Lane <tgl@@sss.pgh.pa.us>
Status: ORr

Bruce Momjian <pgman@@candle.pha.pa.us> writes:
> However, I don't think creating a bpchar
> with no length is a proper solution.  Should we just punt to text in
> these cases?

How many special cases like that do you want to put into the allegedly
datatype-independent CREATE TABLE code?

If I thought this were the only case then I'd not object ... but it
looks like a slippery slope from here.

And --- it's not like replacing "bpchar" with "text" actually buys us
any useful new functionality.  AFAICS it's just a cosmetic thing.

			regards, tom lane

PS: On the other hand, we might consider attacking the problem from
the reverse direction, ie *removing* code.  For example, if there
weren't redundant || operators for char and varchar, then every ||
operation would yield text, and the example we're looking at would
work the way you want for free.  I've thought for awhile that we
could use a pass through pg_proc and pg_operator to remove some
entries we don't really need.

From pgsql-bugs-owner+M2696=candle.pha.pa.us=pgman@@postgresql.org Wed Nov 21 23:26:07 2001
Return-path: <pgsql-bugs-owner+M2696=candle.pha.pa.us=pgman@@postgresql.org>
Received: from rs.postgresql.org (server1.pgsql.org [64.39.15.238] (may be forged))
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAM4Q6v16612
	for <pgman@@candle.pha.pa.us>; Wed, 21 Nov 2001 23:26:06 -0500 (EST)
Received: from postgresql.org (postgresql.org [64.49.215.8])
	by rs.postgresql.org (8.11.6/8.11.6) with ESMTP id fAM4MwN38618
	for <pgman@@candle.pha.pa.us>; Wed, 21 Nov 2001 22:22:58 -0600 (CST)
	(envelope-from pgsql-bugs-owner+M2696=candle.pha.pa.us=pgman@@postgresql.org)
Received: from candle.pha.pa.us (candle.navpoint.com [162.33.245.46])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id fAM4DUm84443;
	Wed, 21 Nov 2001 23:13:30 -0500 (EST)
	(envelope-from pgman@@candle.pha.pa.us)
Received: (from pgman@@localhost)
	by candle.pha.pa.us (8.11.6/8.10.1) id fAM4DSH15042;
	Wed, 21 Nov 2001 23:13:28 -0500 (EST)
From: Bruce Momjian <pgman@@candle.pha.pa.us>
Message-ID: <200111220413.fAM4DSH15042@@candle.pha.pa.us>
Subject: Re: [BUGS] Bug #513: union all changes char(3) column definition
In-Reply-To: <28079.1006402117@@sss.pgh.pa.us> "from Tom Lane at Nov 21, 2001
	11:08:37 pm"
To: Tom Lane <tgl@@sss.pgh.pa.us>
Date: Wed, 21 Nov 2001 23:13:28 -0500 (EST)
cc: Peter Eisentraut <peter_e@@gmx.net>,
   PostgreSQL Development <pgsql-hackers@@postgresql.org>,
   stiening@@cannon.astro.umass.edu, pgsql-bugs@@postgresql.org
X-Mailer: ELM [version 2.4ME+ PL90 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk
Sender: pgsql-bugs-owner@@postgresql.org
Status: OR

> How many special cases like that do you want to put into the allegedly
> datatype-independent CREATE TABLE code?
> 
> If I thought this were the only case then I'd not object ... but it
> looks like a slippery slope from here.
> 
> And --- it's not like replacing "bpchar" with "text" actually buys us
> any useful new functionality.  AFAICS it's just a cosmetic thing.
> 
> 			regards, tom lane
> 
> PS: On the other hand, we might consider attacking the problem from
> the reverse direction, ie *removing* code.  For example, if there
> weren't redundant || operators for char and varchar, then every ||
> operation would yield text, and the example we're looking at would
> work the way you want for free.  I've thought for awhile that we
> could use a pass through pg_proc and pg_operator to remove some
> entries we don't really need.

Can we convert bpchar to text in create table if no typmod is supplied?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@@postgresql.org

From peter_e@@gmx.net Thu Nov 22 12:14:01 2001
Return-path: <peter_e@@gmx.net>
Received: from mout02.kundenserver.de (mout02.kundenserver.de [195.20.224.133])
	by candle.pha.pa.us (8.11.6/8.10.1) with ESMTP id fAMHE0v13505
	for <pgman@@candle.pha.pa.us>; Thu, 22 Nov 2001 12:14:00 -0500 (EST)
Received: from [195.20.224.204] (helo=mrvdom00.schlund.de)
	by mout02.kundenserver.de with esmtp (Exim 2.12 #2)
	id 166xQB-0005p4-00; Thu, 22 Nov 2001 18:13:55 +0100
Received: from p3e9e70dc.dip0.t-ipconnect.de ([62.158.112.220])
	by mrvdom00.schlund.de with esmtp (Exim 2.12 #2)
	id 166xQ9-00065m-00; Thu, 22 Nov 2001 18:13:53 +0100
Date: Thu, 22 Nov 2001 18:21:17 +0100 (CET)
From: Peter Eisentraut <peter_e@@gmx.net>
X-Sender: <peter@@peter.localdomain>
To: Tom Lane <tgl@@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@@candle.pha.pa.us>,
   PostgreSQL Development <pgsql-hackers@@postgresql.org>
Subject: Re: [BUGS] Bug #513: union all changes char(3) column definition 
In-Reply-To: <27975.1006401064@@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.30.0111221803230.766-100000@@peter.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: OR

Tom Lane writes:

> The argument here is about how much intelligence it's reasonable to
> expect the system to have.  It's very clearly not feasible to derive
> a length limit automagically in every case.  How hard should we try?

I would like to know what Proprietary database #1 does with

CREATE TABLE one ( a bit(6) );
INSERT INTO one VALUES ( b'101101' );
CREATE TABLE two ( b bit(4) );
INSERT INTO two VALUES ( b'0110' );
CREATE TABLE three AS SELECT a FROM one UNION SELECT b FROM two;

According to SQL92, clause 9.3, the result type of the union is bit(6).
However, it's not possible to store a bit(4) value into a bit(6) field.
Our current solution, "bit(<nothing>)" is even worse because it has no
real semantics at all (but you can store bit(<anything>) in it,
interestingly).

-- 
Peter Eisentraut   peter_e@@gmx.net


@


1.3
log
@Add mention of CREATE TABLE and atttypmod problems.
@
text
@@


1.2
log
@Remove unused entries.
@
text
@d1 19
a19 14
From tgl@@sss.pgh.pa.us Sun May 23 12:32:34 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA23977
	for <maillist@@candle.pha.pa.us>; Sun, 23 May 1999 12:32:33 -0400 (EDT)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA19926;
	Sun, 23 May 1999 12:32:01 -0400 (EDT)
To: Bruce Momjian <maillist@@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@@postgreSQL.org>
Subject: Re: [HACKERS] DEFAULT fixed 
In-reply-to: Your message of Sat, 22 May 1999 21:12:19 -0400 (EDT) 
             <199905230112.VAA13489@@candle.pha.pa.us> 
Date: Sun, 23 May 1999 12:32:01 -0400
Message-ID: <19923.927477121@@sss.pgh.pa.us>
d21 1
a21 1
Status: ROr
d23 82
a104 36
Bruce Momjian <maillist@@candle.pha.pa.us> writes:
>> It might be best to just bite the bullet and make the parser carry
>> around both the type's OID and typmod at all times.

> I will try to add it, but I must not that there are some cases where I
> don't have access to the atttypmod of the result, so it may not be
> possible to do it in every case.  Perhaps I should just leave this for
> post 6.5, because we don't have any other bug reports on it.

After further thought, I think this may be a more difficult and subtle
issue than we've realized.  In the current state of the system, there
are many places where you have a value that you can only know the type
OID for, not atttypmod --- specifically, any intermediate expression
result.  Barring reworking the entire function-call mechanism to pass
atttypmod around, that's not going to be possible to change.

The only context where you really know atttypmod is where you have
just fetched a value out of a table column or are about to store a
value into a table column.  When storing, you need to be prepared to
coerce the given value to the right type if *either* type OID or
atttypmod is different --- but, in general, you don't know atttypmod
for the given value.  (In the cases I know of, you can deduce it by
examining the value itself, but this requires type-specific knowledge.)

So on the whole I think this is something that has to be dealt with
at the point of storing data into a tuple.  Maybe we need a new
fundamental operation for types that pay attention to atttypmod:
"make this value match the typmod of the target column, which is
thus-and-so".  Trying to attack the problem from the source side by
propagating typmod all around the parser is probably doomed to failure,
because there will be many contexts where there's no way to know it.

Since you have a fix for the only symptom reported to date, I'm
inclined to agree that we should leave well enough alone for now;
there are other, bigger, problems that we need to address for 6.5.
But I think we'll have to come back to this issue later.
d107 171
@


1.1
log
@Update TODO list.
@
text
@@
