Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I see in that discussion you say:
>> Every rowtype Datum will carry its own concrete type.
> Are we storing that on disk in every composite object?
Yup. For a rowtype datum it's not a serious overhead. I realize
that the same is not true of enums :-
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Still thinking a bit more about this ... how about we have output
functions take an optional second argument, which is the type oid?
No. We just undid that for good and sufficient security reasons.
If an output function dep
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Still thinking a bit more about this ... how about we have output
> functions take an optional second argument, which is the type oid?
No. We just undid that for good and sufficient security reasons.
If an output function depends on anything more than
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
What about having the calling code fill in the io type oid in an extra field
in the flinfo?
I don't think that's workable; for one thing there's the problem of
manual invocation of the I/O functions, which is not going to
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> What about having the calling code fill in the io type oid in an extra field
> in the flinfo?
I don't think that's workable; for one thing there's the problem of
manual invocation of the I/O functions, which is not going to provide
any such special ha
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> My idea was to have the functions that need access to the text values
>> look up fcinfo->flinfo->fn_oid and then use that to look up the type
>> info. But that would mean we would need pg_proc entries for these
>> functions for each enu
On Thu, Nov 10, 2005 at 05:26:45PM -0500, Andrew Dunstan wrote:
>
>
> David Fetter wrote:
>
> >On Thu, Nov 10, 2005 at 04:08:29PM -0500, Andrew Dunstan wrote:
> >
> >
> >>Tom Lane wrote:
> >>
> >>>I'm not convinced that using bigint-equivalent space for an enum is
> >>>a mortal sin...
> >>>
> >
David Fetter wrote:
On Thu, Nov 10, 2005 at 04:08:29PM -0500, Andrew Dunstan wrote:
Tom Lane wrote:
I'm not convinced that using bigint-equivalent space for an enum is
a mortal sin...
at least venial ...
Heh.
Would ORDER BY somehow know about enums' given ordering?
On Thu, Nov 10, 2005 at 04:08:29PM -0500, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >I'm not convinced that using bigint-equivalent space for an enum is
> >a mortal sin...
>
> at least venial ...
Heh.
Would ORDER BY somehow know about enums' given ordering?
Cheers,
D
--
David Fetter [
Tom Lane wrote:
I'm not convinced that using bigint-equivalent space for an enum is a
mortal sin...
at least venial ...
cheers
andrew
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://arc
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Well, for one thing, I have no plan to allow explicit setting of the internal
> representational value, as one can do in C. And the fact that it's an int
> underneath is in implementation detail, IMNSHO. After all, KL just advised
> using a text domain
Greg Stark wrote:
I know the tendency has been to want to discourage implicit casts, but I think
this is a good use for them. The whole point of enums is to have syntactic
sugar over integers that let you use nicer syntax but that imposes minimal
additional complexity over simply using integer
On Thu, Nov 10, 2005 at 03:28:55PM -0500, Andrew Dunstan wrote:
> Eek! I would be prepared to go to quite a lot of trouble to avoid that.
>
> My idea was to have the functions that need access to the text values
> look up fcinfo->flinfo->fn_oid and then use that to look up the type
> info. But t
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> My idea was to have the functions that need access to the text values
> look up fcinfo->flinfo->fn_oid and then use that to look up the type
> info. But that would mean we would need pg_proc entries for these
> functions for each enum, even if it's th
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
What I want to have is some builtin functions that can be used as the
input/output/cast/etc functions for each enum type.
The hard part of that is going to be figuring out how to get the
information to the functions about wh
On Thu, Nov 10, 2005 at 01:15:07PM -0500, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > What I want to have is some builtin functions that can be used as the
> > input/output/cast/etc functions for each enum type.
>
> The hard part of that is going to be figuring out how to get
Greg Stark <[EMAIL PROTECTED]> writes:
> Maybe my conception of enums is different from yours. My conception is
> basically that of C enums. Where they're purely a creature of the syntax and
> type system. At run-time they don't make any effort to prevent you from
> treating them as integers.
Well
Tom Lane <[EMAIL PROTECTED]> writes:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > I am looking at creating a few generic functions builtin for the enum
> > stuff. These would be tied to each enum type as it is created. However,
> > they should not really appear in pg_proc initially, as there
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> What I want to have is some builtin functions that can be used as the
> input/output/cast/etc functions for each enum type.
The hard part of that is going to be figuring out how to get the
information to the functions about which enum type they're bein
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I am looking at creating a few generic functions builtin for the enum
stuff. These would be tied to each enum type as it is created. However,
they should not really appear in pg_proc initially, as there wouldn't be
any enum types
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I am looking at creating a few generic functions builtin for the enum
> stuff. These would be tied to each enum type as it is created. However,
> they should not really appear in pg_proc initially, as there wouldn't be
> any enum types to tie them to
Martijn van Oosterhout wrote:
On Thu, Nov 10, 2005 at 12:02:58PM -0500, Andrew Dunstan wrote:
I am looking at creating a few generic functions builtin for the enum
stuff. These would be tied to each enum type as it is created. However,
they should not really appear in pg_proc initially, a
On Thu, Nov 10, 2005 at 12:02:58PM -0500, Andrew Dunstan wrote:
>
> I am looking at creating a few generic functions builtin for the enum
> stuff. These would be tied to each enum type as it is created. However,
> they should not really appear in pg_proc initially, as there wouldn't be
> any en
I am looking at creating a few generic functions builtin for the enum
stuff. These would be tied to each enum type as it is created. However,
they should not really appear in pg_proc initially, as there wouldn't be
any enum types to tie them to anyway. But I want them to have reserved
oids an
24 matches
Mail list logo
