RE: [HACKERS] Re: Postgres for Sunos 4.1.4

It seems to be snagging on 'char16'. It says that
postgres.h is included for the declaration, yet,
when I scan the current postgres.h, char16 is
no where to be found.

My CVS snapshot is from yesterday afternoon.

:) Clark

Clark Evans <clark.evans@manhattanproject.com> writes:

It seems to be snagging on 'char16'.

IIRC, char16 was deleted in 6.4 or maybe earlier (along with the other
special "charN" type names). "char(16)" is the accepted spelling now.

A quick glimpse shows an awful lot of appearances of "char16"
in the contrib area, as well as the tutorial and some residual
uses in the documentation. Sigh. I guess that stuff is not
exercised as regularly as it oughta be.

Do you want to contribute a patch to make the tutorial work again?

regards, tom lane

Clark Evans <clark.evans@manhattanproject.com> writes:

It seems to be snagging on 'char16'.

IIRC, char16 was deleted in 6.4 or maybe earlier (along with the other
special "charN" type names). "char(16)" is the accepted spelling now.

A quick glimpse shows an awful lot of appearances of "char16"
in the contrib area, as well as the tutorial and some residual
uses in the documentation. Sigh. I guess that stuff is not
exercised as regularly as it oughta be.

It was...I removed all references to the char16 type in the tutorial
and documentation when I removed the type itself.

Did someone accidentally commit it back with some other patch?

Darren

I was wondering if this function should be
'wrapped up' and put into the SPI interface.
I did some research and think I could pull
it off.

Currently the tutorial uses this:

bool
c_overpaid( TUPLE t, /* the current instance of EMP */
int4 limit)
{
bool isnull = false;
int4 salary;

salary = (int4) GetAttributeByName(t, "salary", &isnull);

if (isnull)
return false;
return salary > limit;
}

And the regression test uses this:

char
overpaid(tuple)
TUPLE tuple;
{
bool isnull;
long salary;

salary = (long) GetAttributeByName(tuple, "salary", &isnull);
return salary > 699;
}

Here is a proposal:

a) An explanation between a TupleTableSlot
and a HeapTuple / TupleDesc pair. (help?)

Perhaps we call the (TupleTableSlot *) a
QueryTuple ? It's called a TUPLE in the
two above usages, where a TUPLE == (void *)

b) Six more functions (overloaded?)

Existing:

Datum SPI_getbinval(HeapTuple, TupleDesc, int, bool *)
char *SPI_getvalue (HeapTuple, TupleDesc, int)

Two more by index:

Datum SPI_getbinval(TupleTableSlot, int, bool *)
char *SPI_getvalue (TupleTableSlot, int)

Four more by name:

Datum SPI_getbinval(HeapTuple, TupleDesc, char *, bool *)
char *SPI_getvalue (HeapTuple, TupleDesc, char *)
Datum SPI_getbinval(TupleTableSlot, char *, bool *)
char *SPI_getvalue (TupleTableSlot, char *)

Hmmm. Better yet, is there a way to hide
the difference in the SPI by using a 'smart'
structure?

Clark

I was looking at the tutorial code (funcs.c) a bit more
and it seems that a bulk of the work going on for the
"copytext" and "concat16" (soon to be defunct *smile* )
is converting from string to datum and then back again.

Perhaps if two functions were added to the SPI that
did this operation...

Datum SPI_stringtodatum(const char *type, const char *data);
const char *SPI_datumtostring(Datum data);

These two functions would lookup the type in the
type table, find the input/output functions for
the datatype and make the call.

Thoughts?

Clark

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Clark Evans <clark.evans@manhattanproject.com> writes:

It seems to be snagging on 'char16'.

IIRC, char16 was deleted in 6.4 or maybe earlier (along with the other
special "charN" type names). "char(16)" is the accepted spelling now.

A quick glimpse shows an awful lot of appearances of "char16"
in the contrib area, as well as the tutorial and some residual
uses in the documentation. Sigh. I guess that stuff is not
exercised as regularly as it oughta be.

It was...I removed all references to the char16 type in the tutorial
and documentation when I removed the type itself.

Did someone accidentally commit it back with some other patch?

It is the tutorual/func*.* files.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian wrote:

It is the tutorual/func*.* files.

Yes.

Thoughts:

a) In funcs.c, to get it to compile, simply remove
the concat16 function and replace TUPLE with TupleTableSlot .

b) In funcs.c it does not make sense to fix concat16, it
should just be removed.

First, the fix would make it almost identical to 'text',
only you truncate and pad extra spaces at the end, thus
this extra duplication does little for the tutorial.
I think the tutorial should be modified to use another
fixed length data type, mabye a square? This leads to:

Second, from a procedure/trigger builder's perspective,
a SPI_stringtodatum and SPI_datumtostring make more
sence than having the programmer worry about the
internal representation of the data type, this is what
the conversion functions are for anyway.... thus, I
even see the 'copytext' code being replaced with
something seperated from the internal structure of the
database executor with these conversion functions.

c) In funcs.source I could not get this function to compile..

| clark=>
| clark=> CREATE FUNCTION clean_EMP () RETURNS int4
| clark-> AS 'DELETE FROM EMP WHERE EMP.salary <= 0\;
| clark'> SELECT 1 AS ignore_this'
| clark-> LANGUAGE 'sql';
| ERROR: parser: parse error at or near ""

d) I had a weird problem with the columns not showing up..

[clark@monster clark]$ psql
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: clark

clark=> CREATE TABLE EMP (
clark-> name text,
clark-> salary int4,
clark-> age int4,
clark-> dept char(16)
clark-> );
CREATE
clark=>
clark=> INSERT INTO EMP VALUES ('Sam', 1200, 16, 'toy');
INSERT 182188 1
clark=> INSERT INTO EMP VALUES ('Claire', 5000, 32, 'shoe');
INSERT 182189 1
clark=> INSERT INTO EMP VALUES ('Andy', -1000, 2, 'candy');
INSERT 182190 1
clark=> INSERT INTO EMP VALUES ('Bill', 4200, 36, 'shoe');
INSERT 182191 1
clark=> INSERT INTO EMP VALUES ('Ginger', 4800, 30, 'candy');
INSERT 182192 1
clark=> \d emp

Table    = emp
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| name                             | text                             |   var |
| dept                             | char()                           |    16 |
+----------------------------------+----------------------------------+-------+
clark=> select * from emp;
name  |salary|age|dept            
------+------+---+----------------
Sam   |  1200| 16|toy             
Claire|  5000| 32|shoe            
Andy  | -1000|  2|candy           
Bill  |  4200| 36|shoe            
Ginger|  4800| 30|candy           
(5 rows)

Thomas,

If you still want a patch file, I can work on it Sunday.

:) Clark

Can you send me a patch? It would be easier, and less error-prone. Thanks.

Thoughts:

a) In funcs.c, to get it to compile, simply remove
the concat16 function and replace TUPLE with TupleTableSlot .

b) In funcs.c it does not make sense to fix concat16, it
should just be removed.

First, the fix would make it almost identical to 'text',
only you truncate and pad extra spaces at the end, thus
this extra duplication does little for the tutorial.
I think the tutorial should be modified to use another
fixed length data type, mabye a square? This leads to:

Second, from a procedure/trigger builder's perspective,
a SPI_stringtodatum and SPI_datumtostring make more
sence than having the programmer worry about the
internal representation of the data type, this is what
the conversion functions are for anyway.... thus, I
even see the 'copytext' code being replaced with
something seperated from the internal structure of the
database executor with these conversion functions.

c) In funcs.source I could not get this function to compile..

| clark=>
| clark=> CREATE FUNCTION clean_EMP () RETURNS int4
| clark-> AS 'DELETE FROM EMP WHERE EMP.salary <= 0\;
| clark'> SELECT 1 AS ignore_this'
| clark-> LANGUAGE 'sql';
| ERROR: parser: parse error at or near ""

d) I had a weird problem with the columns not showing up..

[clark@monster clark]$ psql
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: clark

clark=> CREATE TABLE EMP (
clark-> name text,
clark-> salary int4,
clark-> age int4,
clark-> dept char(16)
clark-> );
CREATE
clark=>
clark=> INSERT INTO EMP VALUES ('Sam', 1200, 16, 'toy');
INSERT 182188 1
clark=> INSERT INTO EMP VALUES ('Claire', 5000, 32, 'shoe');
INSERT 182189 1
clark=> INSERT INTO EMP VALUES ('Andy', -1000, 2, 'candy');
INSERT 182190 1
clark=> INSERT INTO EMP VALUES ('Bill', 4200, 36, 'shoe');
INSERT 182191 1
clark=> INSERT INTO EMP VALUES ('Ginger', 4800, 30, 'candy');
INSERT 182192 1
clark=> \d emp

Table    = emp
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| name                             | text                             |   var |
| dept                             | char()                           |    16 |
+----------------------------------+----------------------------------+-------+
clark=> select * from emp;
name  |salary|age|dept            
------+------+---+----------------
Sam   |  1200| 16|toy             
Claire|  5000| 32|shoe            
Andy  | -1000|  2|candy           
Bill  |  4200| 36|shoe            
Ginger|  4800| 30|candy           
(5 rows)

Thomas,

If you still want a patch file, I can work on it Sunday.

:) Clark

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026