Tom Lane wrote:
I realized that I can probably fix ATAddForeignKeyConstraint to do the
right thing by having it pass the two actual column types to
can_coerce_type, thus allowing check_generic_type_consistency to kick
in and detect the problem.
Yeah, I came to the same conclusion. No amount of
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So it seems neither can_coerce_type() nor find_coercion_pathway() are
>> really particularly well thought out in terms of what they test or don't
>> test. I'm not very sure what a good refactoring would look like,
>> but I am sure that I
Tom Lane wrote:
So it seems neither can_coerce_type() nor find_coercion_pathway() are
really particularly well thought out in terms of what they test or don't
test. I'm not very sure what a good refactoring would look like,
but I am sure that I don't want all their call sites having to
individua
Tom Lane wrote:
Come to think of it, we really do need some refactoring in
parse_coerce.c.
[snip]
I'm not very sure what a good refactoring would look like,
but I am sure that I don't want all their call sites having to
individually account for ANYfoo types. Any thoughts?
I was
Come to think of it, we really do need some refactoring in
parse_coerce.c. I just realized what CVS HEAD's RI code
does with array types:
regression=# create table aa (f1 int[] primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "aa_pkey" for
table "aa"
CREATE TABLE
regr
Tom Dunstan <[EMAIL PROTECTED]> writes:
> I do have b-tree (and hash) support for enums, so it sounds like I'll
> have to hit the same spot. I've got what I thought was a reasonably
> comprehensive test of all the enum features which passes make check, so
> if there's a likely failure in that co
Tom Lane wrote:
Actually ... now that I re-read that remark, I think you may have done
the wrong things with ANYENUM. I think that ANYENUM may in fact be
closer to ANYARRAY than it is to ANYELEMENT, because ANYELEMENT pretty
nearly means "anything at all" whereas ANYARRAY identifies a subset of
Tom Dunstan wrote:
Tom Lane wrote:
As for actually adding it, grep for all references to ANYELEMENT and add
code accordingly; shouldn't be that hard. Note you'd need to add an
anyarray2 at the same time for things to keep working sanely.
The enum patch [1] does exactly this with an ANYENUM ps
I wrote:
> Tom Dunstan <[EMAIL PROTECTED]> writes:
>> Regarding the type system understanding ANYENUM, most of the type system
>> treats ANYENUM identically to ANYELEMENT, the only parts that really
>> need to understand it are the bits that try to tie down concrete types.
> The reason I'm feel
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Regarding the type system understanding ANYENUM, most of the type system
> treats ANYENUM identically to ANYELEMENT, the only parts that really
> need to understand it are the bits that try to tie down concrete types.
The reason I'm feeling annoyed with
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
ANYENUM? What's the use-case for that?
Well ... *somebody* suggested it here ...
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00457.php
Well, in that usage (ie, for enum I/O functions) it's not actually
> > adding an "anyelement2" pseudotype ... The context was a
> > compatibility SQL function to support Oracle's DECODE function.
>
> The reason it's not in there already is we didn't seem to have quite
> enough use-case to justify it. Do you have more?
No. Even this case, for me, is more an expe
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
ANYENUM? What's the use-case for that?
Well ... *somebody* suggested it here ...
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00457.php
Well, in that usage (ie, for enum I/O functi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ANYENUM? What's the use-case for that?
> Well ... *somebody* suggested it here ...
> http://archives.postgresql.org/pgsql-hackers/2005-11/msg00457.php
Well, in that usage (ie, for enum I/O functions) it's not actually
necessary tha
Tom Lane wrote:
Tom Dunstan <[EMAIL PROTECTED]> writes:
The enum patch [1] does exactly this with an ANYENUM pseudo-type. It
should provide a pretty good overview of what will be required.
ANYENUM? What's the use-case for that? These special cases in the
type system are enough of a p
Tom Dunstan <[EMAIL PROTECTED]> writes:
> The enum patch [1] does exactly this with an ANYENUM pseudo-type. It
> should provide a pretty good overview of what will be required.
ANYENUM? What's the use-case for that? These special cases in the
type system are enough of a pain-in-the-neck for the
Tom Lane wrote:
As for actually adding it, grep for all references to ANYELEMENT and add
code accordingly; shouldn't be that hard. Note you'd need to add an
anyarray2 at the same time for things to keep working sanely.
The enum patch [1] does exactly this with an ANYENUM pseudo-type. It
shoul
"Matt Miller" <[EMAIL PROTECTED]> writes:
> A few months ago at
> http://archives.postgresql.org/pgsql-general/2006-11/msg01770.php the
> notion of adding an "anyelement2" pseudotype was discussed. The context
> was a compatibility SQL function to support Oracle's DECODE function.
> Assuming this
18 matches
Mail list logo
