From: | jwieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian) |
Cc: | Andreas(dot)Zeugswetter(at)telecom(dot)at, pgsql-hackers(at)hub(dot)org |
Subject: | Re: [HACKERS] Re: atttypmod of 0 |
Date: | 1998-02-05 18:19:37 |
Message-ID: | m0y0Vth-000BFRC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> >
> > This time it's during the parser (gdb told me). varcharin()
> > is called with a atttypmod of 0 causing a palloc() of 0
> > bytes. How should a VARCHAR type whithout a specified length
> > behave? Is this type 1 character or a variable size up to
> > 4096?
> >
> > I thought we fixed this on Feb 3. look at
> > parse_expr.c line 104: it should read:
> > if (con->typename != NULL)
> > ! result = parser_typecast(val,
> > con->typename, -1);
> > else
> >
> > I think all funcs calling with atttypmod = 0 are allways wrong, should
> > be -1.
> > or a number > 0 (or 4 if atttypmod includes the VARHDRSZ don't know)
>
> It does include the VARHDRSZ.
So the right check would be "atttypmod > 4" instead of "> 0"
But fixing all the other places to use one and the same
value (0 or -1) would be a good idea.
>
> --
> Bruce Momjian
> maillist(at)candle(dot)pha(dot)pa(dot)us
>
>
Until later, Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-02-05 18:47:34 | Re: [HACKERS] Re: atttypmod of 0 |
Previous Message | Jan Wieck | 1998-02-05 18:10:08 | Trigger and permissions |