From: | Keith Parks <emkxp01(at)mtcc(dot)demon(dot)co(dot)uk> |
---|---|
To: | maillist(at)candle(dot)pha(dot)pa(dot)us |
Cc: | hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Re: varchar() troubles |
Date: | 1998-01-19 18:52:52 |
Message-ID: | 199801191852.SAA20909@mtcc.demon.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks Bruce,
It was obviously not quite as simple a problem as I had 1st imagined.
I did have a root around in the code but could not work out how the
attributes were copied to the newly created table.
Thanks for the fix,
Keith.
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
> emkxp01(at)mtcc(dot)demon(dot)co(dot)uk
> > Bruce,
> >
> > The new varchar() stuff looks good, just a minor problem with "select into"
> > where the new table does not seem to get a copy of the atttypmod value
> > from the source table.
> >
> > I had a quick look at the code but guess you'll find the problem 10 times
> > faster than I could.
>
> OK, I have fixed this. The real way to fix this it to add restypmod to
> Resdom, and pass the value all the way through the engine, so tupDesc
> always has the proper atttypmod value, but it is not clear how to do
> this in the parser, so I put the code back in to just do a lookup in
> execMain/execUtils when doing an SELECT * INTO TABLE.
>
> If we start using atttypmod more, we will have to do this.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Darren King | 1998-01-19 18:53:25 | Max tuple size. |
Previous Message | Bruce Momjian | 1998-01-19 18:12:29 | unixware |