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:
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
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:
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
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
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 enum
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,
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
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:
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 being
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, C
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 the
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
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 the same
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 that
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
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 with
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?
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 [EMAIL
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 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...
at least venial ...
Heh.
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 enum, even if
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 hack.
23 matches
Mail list logo
