Re: RfD: more powerful "any" types
От | Pavel Stehule |
---|---|
Тема | Re: RfD: more powerful "any" types |
Дата | |
Msg-id | 162867790909101220r57ce7e3cn550101c29b384823@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RfD: more powerful "any" types (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: RfD: more powerful "any" types
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
good analyse, thank you 2009/9/10 Tom Lane <tgl@sss.pgh.pa.us>: > Robert Haas <robertmhaas@gmail.com> writes: >> The major downside of such a system is that every place where we now >> count on being able to store a type in a fixed-size field would need >> to be touched. I don't believe that the overall slowdown in parsing >> time would be significant, but I do think it would be a massive, >> highly invasive, highly destabilizing patch. For the level of pain >> involved, there might be better uses of our time, > > Yeah, that's exactly the problem. > > I am not sure that we really *have to* have a non-OID-based type > representation though. We have managed to have composite types without > that, and I don't see why something similar would not work for > functional types. > > But that's all well beyond the immediate problem, which is whether we > need something more flexible than "anyelement". ISTM we had these > not-all-mutually-exclusive ideas on the table: > > 1. Allow the existing "any" pseudotype as an input argument type for PLs. > (AFAICS this is simple and painless; about the only question is whether > we want to keep using the name "any", which because of conflicting with > a reserved word would always need the double quotes.) > I thing so this is possible - I see only one critical point - you cannot validate source in validation time. You have to wait for run time. This is some what we leave in plpgsql. I agree, so this is some time one possible way for high level programming. > 2. Come up with some way to do the equivalent of "variadic any[]", > ie, a variable number of not-all-the-same-type arguments. (This isn't > just a type-system problem, there's also the question of how the type > information would be passed at runtime. IIRC we have a solution at the > C level but not for PLs.) again - this is possible, but there could be some strange cases - because we have not polymorphic assign statement - and there are not real some polymorphic variable type like variant or some similar (but it not big problem to implement it). The bigger problem is cached plan in assign statement, or other statements - minimally in plpgsql. > > 3. Add anyelement2/anyarray2, and maybe also -3 and -4 while at it. > > 4. Instead of #3, allow anyelement(N), which is certainly more flexible > than #3 but would require a much larger investment of work. (I'm > uncertain whether attaching typmods to function arguments/results could > have any interesting or unpleasant semantic side effects. It might be > all good, or maybe not. It would definitely need some thought.) anyelement(n) looks more general. I am not sure about readability. > > 5. Various syntactic sugar to substitute for anyelement. (Not in favor > of this myself, it seems to just complicate matters.) > > Functional types might be interesting in the long run but I don't see > that they alter the need for one or more of these. > There could be some use cases like work-flow systems or maybe scheduler event executor. regards Pavel Stehule > regards, tom lane >
В списке pgsql-hackers по дате отправления: