Tom Lane wrote:
Why not enums? ;-)
Well, macros is how we do it elsewhere for char system columns.
I'm not sure we could rely on the behavior if we declared
pg_type.typtype as an enum type ... and if we don't, there's not
much point.
I was thinking C enums:
enum typtype_type {
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not sure we could rely on the behavior if we declared
pg_type.typtype as an enum type ... and if we don't, there's not
much point.
I was thinking C enums:
enum typtype_type {
TYPTYPE_BASE = 'b',
TYPTYPE_COMPOSITE
Tom Lane wrote:
What bothers me about that is I don't think the C spec mandates the
representation width. If we could guarantee that enum typtype_type
was 1 byte I'd be all for it.
The width is 4 both for the macro and the enum case. Both
#define TYPTYPE_BASE 'b'
and
enum ... {
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
What bothers me about that is I don't think the C spec mandates the
representation width. If we could guarantee that enum typtype_type
was 1 byte I'd be all for it.
The width is 4 both for the macro and the enum case. Both
Gregory Stark wrote:
The width is 4 both for the macro and the enum case. Both
#define TYPTYPE_BASE 'b'
and
enum ... {
TYPTYPE_BASE = 'b',
effectively generate int constants named TYPTYPE_BASE with decimal
value 98. So there are no storage advantages either way.
On Sat, Mar 31, 2007 at 07:47:21PM -0700, Mark Dilger wrote:
OK, I can take a stab at fixing this. I'd like to state some assumptions
so people can comment and reply:
I assume that I need to fix *all* cases where invalid byte encodings get
into the database through functions shipped in
I don't necessarily object to PQexecf() as a shortcut for some
multi-step operation, but I don't think you've got the format string
semantics down yet.
I'm thinking that we could start with the standard conversion
specifiers - those are well understood and would be expected by just
about any
On 2/20/07, Phil Currier [EMAIL PROTECTED] wrote:
Inspired by this thread [1], and in particular by the idea of storing
three numbers (permanent ID, on-disk storage position, display
position) for each column, I spent a little time messing around with a
prototype implementation of column storage
On 2007-04-01, Mark Dilger [EMAIL PROTECTED] wrote:
Do any of the string functions (see
http://www.postgresql.org/docs/8.2/interactive/functions-string.html) run the
risk of generating invalid utf8 encoded strings? Do I need to add checks?
Are there known bugs with these functions in this
Gregory Stark [EMAIL PROTECTED] writes:
We could use enum {} to define the labels and then make a rule that
all actual variables should be declared using char rather than
declaring them as enum typtype. But I fear somebody would get that
wrong some day.
Yeah, that seems to me to be just
[EMAIL PROTECTED] writes:
I don't necessarily object to PQexecf() as a shortcut for some
multi-step operation, but I don't think you've got the format string
semantics down yet.
I'm thinking that we could start with the standard conversion
specifiers - those are well understood and would be
On Sun, April 1, 2007 01:32, Tom Lane wrote:
The idea of OIN is to have a large patent pool that can be
counter-asserted against anyone who doesn't want to play nice.
Mutual assured destruction in the patent sphere, if you will.
And from the participants' point of view, I suppose the big
That's exactly the approach I don't want to take. To implement our
quoting-escape additions, we'll have to stop relying on sprintf and
implement for ourselves whatever standard C escapes we want to
support.
Ok - then it seems like it might make sense to implement PQexecf() in
terms of
Tom Lane wrote:
It seems clear to me that this authorizes, but *does not require*,
the compiler to store an enum field in a byte or short instead of
an int when all the declared values will fit. So if we tried to
do this, we'd have the problem of needing compiler-specific data
type
Martijn van Oosterhout wrote:
There's also the performance angle. The current mbverify is very
inefficient for encodings like UTF-8. You might need to refactor a bit
there...
There appears to be a lot of function call overhead in the current
implementation. In pg_verify_mbstr, the function
The attached patch changes all implicit casts to text to assignment and
cleans up the associated regression test damage. This change has been
discussed for the longest time; I propose that we bite the bullet and
do it now.
The issue described in
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Any page written during a backup has a backup block that would not be
removable by Koichi's tool, so yes, you'd still be safe.
How does it know not to do that?
regards, tom lane
---(end
On 4/1/07, Guillaume Smet [EMAIL PROTECTED] wrote:
Phil, did you make any progress with your patch? Your results seemed
very encouraging and your implementation interesting.
IIRC, the problem was that you weren't interested in working on the
visual/mysqlish column ordering. As the plan was to
Phil Currier wrote:
I haven't done much with it since February, largely because my
available free time evaporated. But I do intend to get back to it
when I have a chance. But you're right, the storage position stuff
I've worked on is completely independent from display positions, and
certainly
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
It seems clear to me that this authorizes, but *does not require*,
the compiler to store an enum field in a byte or short instead of
an int when all the declared values will fit.
FWIW, I never meant to suggest using enums tuple
Mark Dilger [EMAIL PROTECTED] writes:
Refactoring the way these table driven functions work would impact
lots of other code. Just grep for all files #including mb/pg_wchar.h
for the list of them. The list includes interfaces/libpq, and I'm
wondering if software that links against postgres
Mark Dilger [EMAIL PROTECTED] writes:
Refactoring the way these table driven functions work would impact
lots of other code. Just grep for all files #including mb/pg_wchar.h
for the list of them. The list includes interfaces/libpq, and I'm
wondering if software that links against
Tatsuo Ishii [EMAIL PROTECTED] writes:
No, we've never exported those with the intent that client code should
use 'em.
I thought PQescapeString() of 8.3 uses mbverify functions to make sure
that user supplied multibyte string is valid.
Certainly --- but we can change PQescapeString to match
23 matches
Mail list logo
