On Aug 10, 2008, at 20:58, David E. Wheeler wrote:
Just realized that I forgot to add the DROP FUNCTION statements to
the uninstall script. New patch attached.
And this one also includes the casts I added. :-)
Best,
David
citext_casting3.patch.gz
Description: GNU Zip compressed data
Just realized that I forgot to add the DROP FUNCTION statements to the
uninstall script. New patch attached.
Best,
David
citext_casting2.patch.gz
Description: GNU Zip compressed data
On Jul 31, 2008, at 10:42, David E. Wheeler wrote:
On Jul 30, 2008, at 13:10, Tom Lane wrote:
Yes,
On Jul 31, 2008, at 10:42, David E. Wheeler wrote:
Good point --- so new members of STRING category aren't going to be
that
common, except for domains which apparently aren't bothering people
anyway. I'll go ahead and make the change. (I think it's just a
trivial change in
David E. Wheeler wrote:
On Jul 31, 2008, at 10:42, David E. Wheeler wrote:
Wow. Really nice, Tom. Thanks!
The attached patch has all the tests I added to my svn version against
8.3, and for which I had to write 60 additional cast functions.
Ping! Just wanted to make sure this wasn't lost
On Aug 4, 2008, at 11:02, Alvaro Herrera wrote:
Ping! Just wanted to make sure this wasn't lost in the shuffle…
Please add it here: http://wiki.postgresql.org/wiki/CommitFest:2008-09
Sure, although it's a simple refinement (read: tests, mainly) of an
accepted July patch, submitted before
David E. Wheeler wrote:
On Aug 4, 2008, at 11:02, Alvaro Herrera wrote:
Ping! Just wanted to make sure this wasn't lost in the shuffle…
Please add it here: http://wiki.postgresql.org/wiki/CommitFest:2008-09
Sure, although it's a simple refinement (read: tests, mainly) of an
accepted
Hi,
Le mercredi 30 juillet 2008, David E. Wheeler a écrit :
On Jul 30, 2008, at 10:34, Tom Lane wrote:
[ move preferred-type info into the system catalogs ]
UUID and so on aren't considered part of the string category, and
shouldn't be IMHO ... any type that has semantics significantly
On Jul 30, 2008, at 13:10, Tom Lane wrote:
Yes, that was essentially my point. arbitrary string of text types
are probably fairly rare, since one can just use text or citext or
varchar.
Good point --- so new members of STRING category aren't going to be
that
common, except for domains
Tom,
On Tue, Jul 29, 2008 at 2:33 PM, Tom Lane [EMAIL PROTECTED] wrote:
Yeah, that's the point of the proposal. I think the issue has come up
once or twice before, too, else I'd not be so interested in a general
solution. (digs in archives ... there was some discussion of this
in connection
Tom Lane [EMAIL PROTECTED] writes:
So this can fairly obviously be replaced by two new pg_type columns,
say typcategory and typpreferred, where the latter is a bool.
Since the list of categories is pretty short and there's no obvious
reason to extend it a lot, I propose that we just represent
Gregory Stark [EMAIL PROTECTED] writes:
I had a different thought when you posted the original prompt earlier. Instead
of a static list of type categories we could re-use type oids. So if you
belong to a type category you store the oid of the preferred type of that
category in typcategory.
Ryan Bradetich [EMAIL PROTECTED] writes:
On Tue, Jul 29, 2008 at 2:33 PM, Tom Lane [EMAIL PROTECTED] wrote:
Yeah, that's the point of the proposal. I think the issue has come up
once or twice before, too, else I'd not be so interested in a general
solution. (digs in archives ... there was
Hello Tom,
On Wed, Jul 30, 2008 at 7:50 AM, Tom Lane [EMAIL PROTECTED] wrote:
Dunno, I forget what the conclusion was about implicit casting for the
unsigned types in your proposal. Have you experimented with seeing
whether, eg, UNION'ing an unsigned with some signed-integer value
behaves
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 29, 2008, at 16:45, Tom Lane wrote:
[ move preferred-type info into the system catalogs ]
I've committed changes along this line. Please look at CVS HEAD and
re-evaluate which alias functions/operators you still really need.
Nice! Does it
On Jul 30, 2008, at 10:34, Tom Lane wrote:
[ move preferred-type info into the system catalogs ]
I've committed changes along this line. Please look at CVS HEAD and
re-evaluate which alias functions/operators you still really need.
Okay, I'll hunt down some tuits today to hack on that.
Tom Lane [EMAIL PROTECTED] wrote:
and you have to remember that *any* domain created over a string
type
will also be considered to be of string category.
find_coercion_pathway
is looking at types that it's already smashed to base types, so
actually you can get an I/O conversion for a
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 30, 2008, at 10:34, Tom Lane wrote:
The behavior that's hard-wired into parse_coerce.c at the moment
is that only text, varchar, bpchar can be sources or targets of
I/O conversions. While opening it up to citext sounds reasonable,
I'm a lot
On Jul 30, 2008, at 10:42, David E. Wheeler wrote:
I've committed changes along this line. Please look at CVS HEAD and
re-evaluate which alias functions/operators you still really need.
Okay, I'll hunt down some tuits today to hack on that.
The ones you removed all seem to be fine. I'll
On Jul 30, 2008, at 11:09, Tom Lane wrote:
What about enums?
Er, what about them? I don't see that they enter into this at all.
Well, from a user's point of view, they're pretty much just strings…
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 30, 2008, at 11:09, Tom Lane wrote:
What about enums?
Er, what about them? I don't see that they enter into this at all.
Well, from a user's point of view, they're pretty much just strings
But they're a very restricted set of strings; I
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 30, 2008, at 10:34, Tom Lane wrote:
UUID and so on aren't considered part of the string category, and
shouldn't be IMHO ... any type that has semantics significantly
different from arbitrary string of text doesn't belong.
Yes, that was
On Jul 30, 2008, at 12:58, Tom Lane wrote:
Well, from a user's point of view, they're pretty much just strings
But they're a very restricted set of strings; I can't see that there's
any general-purpose use for allowing them as the source or destination
of I/O conversions.
*shrug* Okay, no
On Jul 29, 2008, at 11:41, Tom Lane wrote:
Okay, it's committed with minor revisions --- the biggest thing I
fixed
was the lack of an uninstall script.
Great, thanks!
I saw what you were talking about in terms of still having some
casting
issues: having to put in a quote_literal(citext)
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 29, 2008, at 11:41, Tom Lane wrote:
and I notice that cases like
contrib_regression=# select 'a'::text || 'b'::citext;
ERROR: operator is not unique: text || citext
still don't work even though you put in an alias || operator.
Damn, I
On Jul 29, 2008, at 13:12, Tom Lane wrote:
Damn, I didn't even notice that! Can that be fixed?
Given the present infrastructure I think the only way would be with
two more alias operators, text||citext and citext||text. But that way
madness lies.
I suppose, then, that you're saying that
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 29, 2008, at 13:12, Tom Lane wrote:
Given the present infrastructure I think the only way would be with
two more alias operators, text||citext and citext||text. But that way
madness lies.
I suppose, then, that you're saying that there are
On Jul 29, 2008, at 14:00, Tom Lane wrote:
Well, a rough estimate of the places where implicit coercion to text
might be relevant to resolving ambiguity is
select proname from pg_proc
where 'text'::regtype = any(proargtypes)
group by proname having count(*)1;
select oprname from pg_operator
David E. Wheeler [EMAIL PROTECTED] writes:
Well, there are already citext aliases for all of those operators, for
this very reason. There are citext aliases for a bunch of the
functions, too (ltrim(), substring(), etc.), so I wouldn't worry about
adding more. I've added more of them
On Jul 29, 2008, at 14:33, Tom Lane wrote:
That's exactly what I don't really want to do; if you are adding
aliases
*only* to get rid of ambiguity-errors, and not to alter functionality,
then I think you're doing the wrong thing. Adding more aliases can
easily make the situation worse.
I wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Anyway, would this issue then go away once the type stuff was added
and citext was specified as TYPE = 'S'?
Yeah, that's the point of the proposal.
BTW, I did confirm (by temporarily hacking up TypeCategory()) that
causing citext to
On Jul 29, 2008, at 15:35, Tom Lane wrote:
BTW, I did confirm (by temporarily hacking up TypeCategory()) that
causing citext to appear to be of STRING category eliminates the need
for the extra || operator and quote_literal() function that are in
the current citext code. So the proposed
David E. Wheeler [EMAIL PROTECTED] writes:
On Jul 29, 2008, at 15:35, Tom Lane wrote:
BTW, I did confirm (by temporarily hacking up TypeCategory()) that
causing citext to appear to be of STRING category eliminates the need
for the extra || operator and quote_literal() function that are in
the
On Jul 29, 2008, at 16:45, Tom Lane wrote:
Nice! Does it also allow all of the casts to and from text to
implicitly work, e.g,
No, but we could think about that. Do we really want that to work for
any member of the string category? It seems a bit overly broad to me
...
I was thinking
33 matches
Mail list logo
