Heikki Linnakangas writes:
> When the set-returning-function feature was written originally, years
> ago, the tuple at a time mode did really work tuple at a time. But it
> had issues and was axed out of the patch before it was committed, to
> keep it simple. The idea was to revisit it at some poi
On Wed, 27 Jan 2010 22:06:43 +0200
Heikki Linnakangas wrote:
> Ivan Sergio Borgonovo wrote:
> > But then... why do we have all that logic to save the function
> > context if anyway it is more convenient to process everything in
> > one run?
> > It's a pain to save the context just to save a point
On Jan 27, 2010, at 1:00 PM, Joe Conway wrote:
> Implementing true value_per_call is still something on my TODO list, but
> obviously has not risen to a very high priority for me as it has now
> been an embarrassing long time since it was put there. But that said,
> materialize mode has proven extr
Ivan Sergio Borgonovo wrote:
> But then... why do we have all that logic to save the function
> context if anyway it is more convenient to process everything in one
> run?
> It's a pain to save the context just to save a pointer inside a
> structure, it would be more convenient to just process all
On 01/27/2010 09:49 AM, Ivan Sergio Borgonovo wrote:
> On Wed, 27 Jan 2010 17:37:23 +0200
> Heikki Linnakangas wrote:
>
>> Currently, there's no difference in terms of memory needs. The
>> backend always materializes the result of a SRF into a tuplestore
>> anyway, if the function didn't do it it
On Wed, 27 Jan 2010 17:37:23 +0200
Heikki Linnakangas wrote:
> Currently, there's no difference in terms of memory needs. The
> backend always materializes the result of a SRF into a tuplestore
> anyway, if the function didn't do it itself. There has been
> discussion of optimizing away that mate
Ivan Sergio Borgonovo wrote:
Is there a book?
You'll find a basic intro to this area in "PostgreSQL Developer's
Handbook" by Geschwinde and Schonig. You're already past the level of
questions they answer in there though. This whole cstring/text issue
you're asking about, I figured out b
Ivan Sergio Borgonovo wrote:
> On Wed, 27 Jan 2010 11:49:46 -0300
> Alvaro Herrera wrote:
>
> > > There are a lot of functions in contrib taking cstring input and
> > > returning cstring output.
> > > Are they just in the same "special" class of [type]in, [type]out
> > > [type]recv... functions?
Ivan Sergio Borgonovo wrote:
> I'm more interested in understanding when I should use materialized
> mode.
> eg. I should be more concerned about memory or cpu cycles and what
> should be taken as a reference to consider memory needs "large"?
> If for example I was going to split a large TEXT into
Ivan Sergio Borgonovo wrote:
On Wed, 27 Jan 2010 10:10:01 -0500
Andrew Dunstan wrote:
There are quite a few SRF functions in the code. Look for example
in contrib/hstore/hstore_op.c for some fairly simple examples.
SRFs are quite capable of returning huge resultsets, not just
small ones.
On Wed, 27 Jan 2010 10:10:01 -0500
Andrew Dunstan wrote:
> There are quite a few SRF functions in the code. Look for example
> in contrib/hstore/hstore_op.c for some fairly simple examples.
> SRFs are quite capable of returning huge resultsets, not just
> small ones. Example code for matrerialize
Ivan Sergio Borgonovo wrote:
> There are a lot of functions in contrib taking cstring input and
> returning cstring output.
> Are they just in the same "special" class of [type]in, [type]out
> [type]recv... functions?
If you're looking in contrib subdirectories, perhaps the missing
link here i
On Wed, 27 Jan 2010 11:49:46 -0300
Alvaro Herrera wrote:
> > There are a lot of functions in contrib taking cstring input and
> > returning cstring output.
> > Are they just in the same "special" class of [type]in, [type]out
> > [type]recv... functions?
> Probably, but I didn't check.
Does this
Ivan Sergio Borgonovo wrote:
I just learned there is a "return all row" mode for returning set
functions:
"
There are currently two modes in which a function can return a set
result: value-per-call, or materialize. In value-per-call mode, the
function returns one value each time it is called,
Ivan Sergio Borgonovo wrote:
> What's not included in "on SQL level almost everything is text"?
input and output functions always use cstring rather than text. The I/O
functions are normally not used directly at the SQL level.
> There are a lot of functions in contrib taking cstring input and
>
On Wed, 27 Jan 2010 21:41:02 +0800
Craig Ringer wrote:
> I don't code on PostgreSQL's guts, so I'm perhaps not in the best
> position to speak, but:
>
> - Documentation has a cost too, particularly a maintenance cost.
> Outdated docs become misleading or downright false and can be much
> more
On Wed, 27 Jan 2010 14:44:02 +0100
Martijn van Oosterhout wrote:
> On Wed, Jan 27, 2010 at 02:14:36PM +0100, Ivan Sergio Borgonovo
> wrote:
> > I haven't been able to understand the difference between function
> > returning cstring and text and if there is any need to be careful
> > about encodin
> Is there any difference from function returning text and function
> returning cstring?
>
text is varlena type - it could be TOASTed, comprimated. It is better
integrated to PostgreSQL world. cstring is just C zero terminated
string - so good for system call, call some external libraries.
Regard
On Wed, Jan 27, 2010 at 02:14:36PM +0100, Ivan Sergio Borgonovo wrote:
> I haven't been able to understand the difference between function
> returning cstring and text and if there is any need to be careful
> about encoding and escaping when copying from the lexeme to a buffer
> that will return a
On 27/01/2010 9:14 PM, Ivan Sergio Borgonovo wrote:
On Mon, 25 Jan 2010 16:36:46 -0600
"Kevin Grittner" wrote:
Ivan Sergio Borgonovo wrote:
The README files might be a good place to start, then browse code.
Is there a book?
The more I read the source and the few info about it, the more I
On Mon, 25 Jan 2010 16:36:46 -0600
"Kevin Grittner" wrote:
> Ivan Sergio Borgonovo wrote:
>
> The README files might be a good place to start, then browse code.
Is there a book?
The more I read the source and the few info about it, the more I
have questions that should have been answered by
Ivan Sergio Borgonovo wrote:
The README files might be a good place to start, then browse code.
> Is there any part of the code from where I could learn about:
> - memory allocation for both cstring and text
src/backend/utils/mmgr/README
> - example of returning text (especially if size of
I'm having a hard time trying to understand how everything should be
done in C extensions.
Now I'm trying to understand how and when I should accept/return
cstring vs text and if and how I should take care of any encoding.
I'm trying to output the content of a tsvector as a set of record
pos, wei
23 matches
Mail list logo
