Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this something for 8.3 or 8.4?
My goodness, you are a bit behind on the email. We fixed that a month ago.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.
Is this something for 8.3 or 8.4?
---
Tom Lane wrote:
> The current discussion about the tsearch-in-core patch has convinced me
> that there are plausible use-cases for typmod values that aren't simple
> integers. For inst
On Fri, 2007-06-15 at 15:01 -0400, Stephen Frost wrote:
> But we'd only get 31 bits of room to encode that into. I'm not sure if
> that's enough. :( At the moment there's three columns we're talking
> about in the side-table:
> SRID (integer)
> TYPE (varchar(30))
> DIMENSIONS (integer)
>
> Now,
Stephen Frost <[EMAIL PROTECTED]> writes:
> Any chance of this being increased?
No. Changing typmod to something other than int32 would require many
thousands of lines of diffs just in the core distro. I don't even want
to think about how much outside code would break.
r
I propose changing the typmodin signature to "typmodin(cstring[]) returns
int4", that is, the typmods will be passed as strings not integers. This
will incur a bit of extra conversion overhead for the normal uses where
the typmods are integers, but I think the gain in flexibility is worth
agree
Am Freitag, 15. Juni 2007 18:14 schrieb Tom Lane:
> The current discussion about the tsearch-in-core patch has convinced me
> that there are plausible use-cases for typmod values that aren't simple
> integers. For instance it could be sane for a type to want a locale or
> language selection as a t
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Would this allow for 'multi-value' typmods for user-defined types?
>
> If you can squeeze them into 31 bits of stored typmod, yes. That
> may mean that you still need the side table (with stored typmod being a
>
Is it worth providing an ArrayGetStringTypmods in core, when it won't
be used by any existing core datatypes?
I don't think so - cstring[] is a set of strings itself. I don't believe that we
could suggest something commonly useful without some real-world examples.
--
Teodor Sigaev
Stephen Frost <[EMAIL PROTECTED]> writes:
> Would this allow for 'multi-value' typmods for user-defined types?
If you can squeeze them into 31 bits of stored typmod, yes. That
may mean that you still need the side table (with stored typmod being a
lookup key for the table). But this gets you out
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> I propose changing the typmodin signature to "typmodin(cstring[]) returns
>> int4", that is, the typmods will be passed as strings not integers.
> And modify ArrayGetTypmods() to ArrayGetIntegerTypmods()
Right --- the decoding work will only have to ha
* Tom Lane ([EMAIL PROTECTED]) wrote:
> I propose changing the typmodin signature to "typmodin(cstring[]) returns
> int4", that is, the typmods will be passed as strings not integers. This
> will incur a bit of extra conversion overhead for the normal uses where
> the typmods are integers, but I t
On Fri, Jun 15, 2007 at 12:14:45PM -0400, Tom Lane wrote:
[snip]
> I propose changing the typmodin signature to "typmodin(cstring[])
> returns int4", that is, the typmods will be passed as strings not
> integers. This will incur a bit of extra conversion overhead for
> the normal uses where the
The current discussion about the tsearch-in-core patch has convinced me
that there are plausible use-cases for typmod values that aren't simple
integers. For instance it could be sane for a type to want a locale or
language selection as a typmod, eg tsvector('ru') or tsvector('sv').
(I'm not sayin
13 matches
Mail list logo
