[DOCS] [PATCH] Use idiomatic style for varlena structs

#1

I'm new to the codebase, but I think this patch reflects real-world usage;
the PostgreSQL code itself always calls the length field "vl_len_", and I
believe int32 is preferred over int4 (yes?)

Jay Levitt

--
Sent via pgsql-docs mailing list (pgsql-docs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

#2

Jay Levitt <jay.levitt (AT) gmail (DOT) com> writes:

Quote:

I'm new to the codebase, but I think this patch reflects real-world usage;
the PostgreSQL code itself always calls the length field "vl_len_", and I
believe int32 is preferred over int4 (yes?)

The point of calling it vl_len_ is that it should never be referenced by
that name, so I'm not sure that propagating that name into user
documentation is a good idea. I do agree with the part of this patch
that recommends use of SET_VARSIZE.

For context, the issues you're concerned about only matter when dealing
with a toastable datatype (not all varlena types are toastable). The
particular bit of docs here doesn't pretend to be explaining how to
write toast-safe code. I think it might be better from an expository
standpoint to cover that separately, rather than try to work it into the
very first pass over the concepts.

regards, tom lane

--
Sent via pgsql-docs mailing list (pgsql-docs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

#3

Tom Lane wrote:

Quote:

Jay Levitt<jay.levitt (AT) gmail (DOT) com> writes:
I'm new to the codebase, but I think this patch reflects real-world usage;
the PostgreSQL code itself always calls the length field "vl_len_", and I
believe int32 is preferred over int4 (yes?)

The point of calling it vl_len_ is that it should never be referenced by
that name, so I'm not sure that propagating that name into user
documentation is a good idea. I do agree with the part of this patch
that recommends use of SET_VARSIZE.

Ah, ok. My confusion came from trying to build a new extension, using cube
as a baseline; cube (and all the other contrib extensions) use vl_len_, so I
saw a disconnect between the "int4 length" in the manual and the
"int32 vl_len_" in all the real-world examples I had.

My thought was that "vl_len_" *feels* more like a "this is mysterious and
I'd better not touch it - I'll use that macro", while "length" feels more
like something I might just set myself if I didn't know better. But maybe
not. Either way, the int32/int4 thing should be fixed.

Quote:

For context, the issues you're concerned about only matter when dealing
with a toastable datatype (not all varlena types are toastable). The
particular bit of docs here doesn't pretend to be explaining how to
write toast-safe code. I think it might be better from an expository
standpoint to cover that separately, rather than try to work it into the
very first pass over the concepts.

Definitely; if anything, that's why I was favoring vl_len_. This is a magic
field. Do not touch the magic.

Jay

--
Sent via pgsql-docs mailing list (pgsql-docs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

#4

On Mon, Feb 13, 2012 at 1:57 PM, Jay Levitt <jay.levitt (AT) gmail (DOT) com> wrote:

Quote:

Tom Lane wrote:

Jay Levitt<jay.levitt (AT) gmail (DOT) com> *writes:

I'm new to the codebase, but I think this patch reflects real-world
usage;
the PostgreSQL code itself always calls the length field "vl_len_", andI
believe int32 is preferred over int4 (yes?)

The point of calling it vl_len_ is that it should never be referenced by
that name, so I'm not sure that propagating that name into user
documentation is a good idea. *I do agree with the part of this patch
that recommends use of SET_VARSIZE.

Ah, ok. *My confusion came from trying to build a new extension, using cube
as a baseline; cube (and all the other contrib extensions) use vl_len_, so I
saw a disconnect between the "int4 length" in the manual and the
"int32 vl_len_" in all the real-world examples I had.

My thought was that "vl_len_" *feels* more like a "this is mysterious and
I'd better not touch it - I'll use that macro", while "length" feels more
like something I might just set myself if I didn't know better. *But maybe
not. *Either way, the int32/int4 thing should be fixed.

For context, the issues you're concerned about only matter when dealing
with a toastable datatype (not all varlena types are toastable). *The
particular bit of docs here doesn't pretend to be explaining how to
write toast-safe code. *I think it might be better from an expository
standpoint to cover that separately, rather than try to work it into the
very first pass over the concepts.

Definitely; if anything, that's why I was favoring vl_len_. This is a magic
field. Do not touch the magic.

I've committed the parts of this to which Tom did not object.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-docs mailing list (pgsql-docs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

[DOCS] [PATCH] Use idiomatic style for varlena structs

mailing.database.pgsql-docs mailing.database.pgsql-docs

[DOCS] [PATCH] Use idiomatic style for varlena structs - 02-13-2012 , 08:45 AM

Re: [DOCS] [PATCH] Use idiomatic style for varlena structs - 02-13-2012 , 09:51 AM

Re: [DOCS] [PATCH] Use idiomatic style for varlena structs - 02-13-2012 , 12:57 PM

Re: [DOCS] [PATCH] Use idiomatic style for varlena structs - 03-22-2012 , 01:49 PM