Skip site navigation (1) Skip section navigation (2)

Re: doubt about datum

From: Luca Ferrari <fluca1978(at)infinito(dot)it>
To: pgsql-novice(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: doubt about datum
Date: 2007-07-31 07:07:56
Message-ID: 200707310907.56878.fluca1978@infinito.it (view raw or flat)
Thread:
Lists: pgsql-novice
On Tuesday 31 July 2007 your cat, walking on the keyboard, wrote:
> Luca Ferrari <fluca1978(at)infinito(dot)it> writes:
> > I'm new to postgresql programming and I'd like to understand what a datum
> > is
>
> A value of any data type -- which particular type is not said by the
> datum itself, but we always have context information to tell us that.

Not sure to get this. With "any data type" you mean user defined types or also 
internal data types? I guess the former. And what do you mean by "context"? I 
noticed that Datum is used as return type in the function v1 convention, thus 
I guess the context is related to the function itself, which return type is 
know by the SQL side. Is this what you mean?


>
> > Moreover why it does not need transaction
> > visibility as an ordinary tuple (xmin, cmin, cmax, xmax)?
>
> Datums are values.  '42'::int does not need visibility information;
> its value is always the same.


Even more confused here! In the case of function returns values I agree that 
there is no needing for transaction information, since the value should be 
evaluated on the fly, right? Maybe what I'm not getting is about a tuple that 
includes both internal values and a datum: is that possibile? Because in this 
case how is the tuple header handled (since datum header should overlap the 
transaction header xmin,xmax...). Sorry if my question is too trivial.

Thanks,
Luca


In response to

pgsql-novice by date

Next:From: Peter ChildsDate: 2007-07-31 07:54:15
Subject: Re: [NOVICE] alter table table add column
Previous:From: Ronald RojasDate: 2007-07-31 06:37:28
Subject: Re: [NOVICE] alter table table add column

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group