2013/10/28 Andres Freund <and...@2ndquadrant.com> > On 2013-10-28 09:13:06 +0100, Hugo Mercier wrote: > > Le 25/10/2013 18:44, Tom Lane a écrit : > > > Hugo Mercier <hugo.merc...@oslandia.com> writes: > > >> Le 25/10/2013 17:20, Tom Lane a écrit : > > >>> How do you tell the difference between > > >>> > > >>> foo(col1, bar(col2)) > > >>> foo(bar(col1), col2) > > > > > >> Still not sure to understand ... > > >> I assume foo() takes two argument of type A. > > >> bar() can take one argument of A or another type B. > > > > > > I was assuming everything was the same datatype in this example, ie > > > col1, col2, and the result of bar() are all type A. > > > > > > The point I'm trying to make is that in the first case, foo would be > > > receiving a first argument that was flat and a second that was not > flat; > > > while in the second case, it would be receiving a first argument that > was > > > not flat and a second that was flat. The expression labeling you're > > > proposing does not help it tell the difference. > > > > No it does not. It's then up to the data type to store whether it is > > flat or not. And every functions manipulating this type is assumed to be > > aware of this flat/non-flat flagging. > > But what if the in-memory type contains pointers and is copied or > spilled to disk? There needs to be a mechanism handling that case. > > > > Basically the only way to make this work reliably is for Datums to be > > > self-identifying as to whether they're flat or structured values; then > > > make code do the right thing on-the-fly at runtime depending on what > kind > > > of Datum it gets. Once you've done that, I don't see that parse-time > > > labeling of expression nesting adds anything useful. As Andres said, > > > the provisions for toasted datums are a good precedent, and none of > that > > > depends on parse-time decisions. > > > > > > > This is something I have to investigate, thanks for pointing it out. > > What I've understood so far is that there is room for new flags in the > > TOAST mechanism, so the idea would be to add a new strategy where opaque > > pointers could be stored. And it would then require a way for extensions > > to register their own "(de)toasting" functions, right ? > > I think we'd need another argument to CREATE FUNCTION like SERIALIZE > pointing to a function that that has to return data that can be stored > on disk. Deserialization would be up to individual functions. > > Depending on the specification this might turn out to be slightly > invasive, tuplestore/sort et al probably have to care... >
Then you need a functions than prepare a clone of unpacked data too. Regards Pavel > > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
