On Sat, May 10, 2008 at 11:02 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Where are we on this?
I haven't had time to do any work since the original patch. That patch
was fairly basic - it just ran install / uninstall scripts and created
catalog entries, and introduced some slightly exotic
On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark [EMAIL PROTECTED] wrote:
I wonder if there's much of a use case for any statements aside from CREATE
statements. If we restrict it to CREATE statements we could hack things to
create pg_depend entries automatically. In which case we wouldn't need
On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan [EMAIL PROTECTED] wrote:
On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark [EMAIL PROTECTED] wrote:
I wonder if there's much of a use case for any statements aside from
CREATE
statements. If we restrict it to CREATE statements we could hack
Sorry to keep replying to myself, but part of the point of doing a
patch was to force myself (and whoever else is interested to examine
stuff that comes up...
On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan [EMAIL PROTECTED] wrote:
None of that suggests that an uninstaller script would be needed
On Mon, Apr 7, 2008 at 7:55 PM, Tom Lane [EMAIL PROTECTED] wrote:
Tom Dunstan [EMAIL PROTECTED] writes:
OK, I found an example that does NOT fit the just drop all
dependencies scenario, but that I would still like to support. I just
had a look at the postgis pl/java support, and its
Hi all
Here is a patch that provides an initial implementation of the module
idea that was kicked around over the last few days. While there
certainly wasn't consensus on list, enough people seemed interested in
the idea of database-owner-installable modules that I thought it was
worth having a
Looks like we need to check the length on type creation
too.
I'll fix later if not beaten to it.
It works for me (ie fails with an appropriate error) locally
on Linux FC6 x86-64. Perhaps this platform initializes
memory to zero on allocation? I dunno. Anyway, if you can
reproduce it, please
Hm, I suppose we should apply truncate_identifier rather than letting
the strings be blindly truncated (perhaps in mid-character). Should we
have it throw the truncation NOTICE, or not? First thought is to do so
during CREATE TYPE but not during plain enum_in().
I don't see much point in
Tom Lane wrote:
While all this reasoning is perfectly OK on its own terms, it ignores
the precedents of SQL identifier handling. Maybe we should revisit the
question of whether the labels are identifiers.
Implying that they shouldn't be quoted like text (or should be
double-quoted if
Tom Lane wrote:
But probably making them act like identifiers is not a good idea,
because I doubt we want automatic downcasing in enum_in. People
wouldn't be happy if they had to write WHERE color = 'Red' or
something like that to get at a mixed-case enum label.
Ah, that's what you had in
Andrew Dunstan wrote:
Tom Lane wrote:
enum_first, enum_last: these return ANYENUM but violate the rule that
a polymorphic-result function must have a polymorphic input argument
from which the parser may deduce the actual output type.
Is this a tragedy when the supplied parameter gives the
text_enum: same problem as above, plus not acceptable to assume that it
gets the right enum OID, plus very definitely not acceptable to assume
that OID and typmod are the same size, plus I don't like the
undocumented kluge in getBaseTypeAndTypmod that is pretending to supply
the type OID for some
Tom Lane wrote:
The null Datum itself obviously doesn't carry that info, but the
expression tree does, and there are provisions for letting functions
retrieve that info --- see get_fn_expr_rettype and get_fn_expr_argtype.
Hmm. I vaguely remember that there was some feeling that the PLs
Tom Lane wrote:
OK, I give up. :) Why?
Because the whole point is that the type has to be known at parse time.
Oh, duh. :)
I've got it working with get_fn_expr_argtype and it seems fairly
reasonable.
Cool!
Thanks
Tom
---(end of
Hi all! Thanks for reviewing the patch!
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Is there a specific reason for
pg_enum.enumname to be type name and not type text?
IIRC at one stage Tom wanted to try to make these identifiers, but that
was quickly abandoned.
Tom Lane wrote:
Unless someone objects, I'll change this and also revert to the
enumlabel name that seems to have been used originally (it was still
used in the docs). It seems more readable somehow (I guess it's the
lack of either ascenders or descenders in enumname).
The name/text thing
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
If you want to review or test the feature, the attached patch can be
used as a replacement for the portion that affects parse_coerce.c, and
with this it compiles and passes regression. I think it's correct but it
should still be OKed by
Hi all
Here's the current version of the enums patch. Not much change from last
time, the only thought-inducing stuff was fixing up some macros that
changed with the VARLENA changes, and adding a regression test to do
basic checking of RI behavior, after the discussions that we had
recently
Neil Conway wrote:
On Thu, 2007-02-01 at 22:50 -0500, Bruce Momjian wrote:
Where are we on this?
I can commit to reviewing this. The patch looked fairly solid on a quick
glance through, but I won't have the cycles to review it properly for a
week or two.
I've brought this up to date with
Heikki Linnakangas wrote:
I'm sorry I missed the original discussions, but I have to ask: Why do
we want enums in core? The only potential advantage I can see over using
a look-up table and FK references is performance.
Well, there are a few things. Sometimes its tidiness, sometimes
Alvaro Herrera wrote:
I don't, because there are always those that are knowledgeable enough to
know how to reduce space lost to padding. So it would be nice to have
2-byte enums on-disk, and resolve them based on the column's typid. But
then, I'm not familiar with the patch at all so I'm not
Peter Eisentraut wrote:
An objection to enums on the ground that foreign keys can accomplish the
same thing could be extended to object to any data type with a finite
domain.
Exactly. The extreme case is the boolean type, which could easily be
represented by a two-value enum. Or, if you were
Hi all
Here is an updated version of the enums patch. It has been brought up to
date and applies against current CVS HEAD. The original email is at [1],
and describes the implementation.
This version contains sgml documentation, and contains the missing
bounds checks and error codes noted
Hi folks
Here's a first cut of the enums patch for feedback when people have
time. It follows an anyenum pseudo-type approach as foreseen by
Nostradamus in one of the original threads.
(http://archives.postgresql.org/pgsql-hackers/2005-11/msg00457.php).
That made the patch a little more
24 matches
Mail list logo
