Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Is there a chance to commit this patch to 8.2?
No. It's not within hailing distance of done, and by the time it was
done we'd be stretching the feature freeze deadline beyond all reason.
I encourage you to work on it with an eye to 8.3 though.
On Thu, Aug 03, 2006 at 05:37:21PM -0700, elein wrote:
> I can think of histograms as a data type which may take more than one
> argument,
> maybe even an array for boundary information. I think the direction *in the
> long term* should be to allow multiple arguments (as a ROW type?) and other
>
>> But that makes NUMERIC(x,y) impossible to represent.
Well, we have to special-case INTERVAL anyway (because its cramming some
truly bizarre things into typmod), and it wouldn't bother me too much to
special-case NUMERIC as well.
We have a lot of special transformation of type based on typmo
On Thu, Aug 03, 2006 at 05:04:47PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Thu, Aug 03, 2006 at 04:18:53PM -0400, Tom Lane wrote:
> >> I think we could legislate that the stored typmod is the same as what
> >> the user sees (and can't be negative). The fact that it's differ
Martijn van Oosterhout writes:
> On Thu, Aug 03, 2006 at 04:18:53PM -0400, Tom Lane wrote:
>> I think we could legislate that the stored typmod is the same as what
>> the user sees (and can't be negative). The fact that it's different
>> for some of the built-in types is a historical artifact tha
On Thu, Aug 03, 2006 at 04:18:53PM -0400, Tom Lane wrote:
> > Also, there's the issue of converting
> > the arguments to a typmod, in the long term it'd have to be
> > user-defined per type.
>
> I think we could legislate that the stored typmod is the same as what
> the user sees (and can't be neg
Martijn van Oosterhout writes:
> I'm surprised you got the patch so small. Mind you, you didn't do any
> folding in the productions for NUMERIC and CHAR which in the long term
> would probably need to be done.
Yeah, the patch ought to be making the grammar smaller not bigger.
> Also, there's the
I'm surprised you got the patch so small. Mind you, you didn't do any
folding in the productions for NUMERIC and CHAR which in the long term
would probably need to be done. Also, there's the issue of converting
the arguments to a typmod, in the long term it'd have to be
user-defined per type.
Stil
or so timeframe ... but feel free to improve it if you can.
I'm not very familiar with yacc/bison, so pls, review attached patch. I may miss
something... It's based on ideas in previous discussions:
http://www.pgsql.ru/db/mw/msg.html?mid=1995063
http://www.pgsql.ru/db/mw/msg.html?mid=2091842
Martijn van Oosterhout writes:
>
> No kidding, it's quite a mess and really needs to be cleaned up. About
> the only thing we could do would be to merge the productions for types
> and functions. Or at least, make the productions look similar enough
> that bison can avoid deciding which it is un
On Tue, Aug 01, 2006 at 06:47:31PM +0400, Teodor Sigaev wrote:
> >Not really, but that's another thing that seems unreasonably hard to
> >fix.
> >
> Sorry, but more problem:
No kidding, it's quite a mess and really needs to be cleaned up. About
the only thing we could do would be to merge the pr
Not really, but that's another thing that seems unreasonably hard to
fix.
Sorry, but more problem:
1)
postgres=# select 'as'::pg_catalog.char, 'as'::char, 'as'::char(2);
char | bpchar | bpchar
--++
a| a | as
(1 row)
postgres=# select 'as'::pg_catalog.char(2);
ERR
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> postgres=# select text[] '{asd}';
> ERROR: syntax error at or near "]"
> LINE 1: select text[] '{asd}';
> Is it desired effect?
Not really, but that's another thing that seems unreasonably hard to
fix.
regards, tom lane
--
char(42) 'literal value here'
Playing around that I noticed:
postgres=# select '{asd}'::text[], '{asd}'::_text, _text '{asd}';
text | _text | _text
---+---+---
{asd} | {asd} | {asd}
(1 row)
postgres=# select text[] '{asd}';
ERROR: syntax error at or near "]"
LINE 1: se
Martijn van Oosterhout writes:
> No. Search the archives for discussions about "user defined typmod".
> The basic problem came down too that the set of allowed words for
> functions and types would be forced to be the same (due to restrictions
> in lookahead), and people wern't happy with that bec
On Mon, Jul 31, 2006 at 05:04:00PM +0400, Teodor Sigaev wrote:
> Is it possible to create user-defined type with optional length in create
> table similar to char()/varchar()/bit()? Without modification gram.y of
> course...
No. Search the archives for discussions about "user defined typmod".
Th
Is it possible to create user-defined type with optional length in create table
similar to char()/varchar()/bit()? Without modification gram.y of course...
Thank you.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
17 matches
Mail list logo
