> 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 bu
Bruce Momjian <[EMAIL PROTECTED]> 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 t
> 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
Bruce Momjian <[EMAIL PROTECTED]> 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 create
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> CREATE TABLE AS cannot be expected to be able to extract a suitable
> >> typmod from complex expressions.
>
> > I don't think that would be entirely unreasonable.
>
> Well, it might not be completely impossible, but I think
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
> Edward Grabczewski ([EMAIL PROTECTED]) reports a bug with a severity
>of 1
> The lower the number the more severe it is.
>
> Short Description
> SERIAL type value not seen in FOREIGN KEY
>
> Long Description
> I have defined a table called arch_ob
Edward Grabczewski ([EMAIL PROTECTED]) reports a bug with a severity
of 1
The lower the number the more severe it is.
Short Description
SERIAL type value not seen in FOREIGN KEY
Long Description
I have defined a table called arch_object which contains a SERIAL type.
I have defined another tabl
