Ühel kenal päeval, T, 2007-02-13 kell 09:38, kirjutas Tom Lane:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Hannu Krosing wrote:
Are we actually doing that ? I.E are null bitmaps really allocated in 1
byte steps nowadays ?
Yes.
Not really; we still have to MAXALIGN at the end of the
Regarding the advisory on possibly insecure security definer functions
that I just sent out (by overriding the search path you can make the
function do whatever you want with the privileges of the function
owner), the favored solution after some initial discussion in the core
team was to
This is a WIP patch based on the recent posting by Simon and discussions
thereafter. We are trying to do one piece at a time and intention is to post
the work ASAP so that we could get early and continuous feedback from
the community. We could then incorporate those suggestions in the next
WIP
Am Mittwoch, 14. Februar 2007 10:21 schrieb Zeugswetter Andreas ADI SD:
Have you considered hardcoding the schema for each object where it was
found at creation time ?
Unless anyone has solved the halting problem lately, I don't think it's
possible to determine at creation time which objects
Our docs for the integer datetime option says:
Use 64-bit integer storage for datetimes and intervals, rather than the
default floating-point storage. This reduces the range of representable
values but guarantees microsecond precision across the full range (see
Section 8.5 for more information).
Tom Lane wrote:
As for actually adding it, grep for all references to ANYELEMENT and add
code accordingly; shouldn't be that hard. Note you'd need to add an
anyarray2 at the same time for things to keep working sanely.
The enum patch [1] does exactly this with an ANYENUM pseudo-type. It
Magnus Hagander wrote:
I've been looking at backporting the stats fix committed to head and 8.2
into 8.1, but realised that it's just not going to work. 8.1 still uses
the dual stats processor stuff, which means that the simplification just
is not possible.
The most obvious result is that
Tom Lane wrote:
Jacob Rief [EMAIL PROTECTED] writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating environment is C not C++. If you dumb it down enough
--- no exceptions, no RTTI, no use of C++ library --- then it
Andreas Pflug wrote:
Tom Lane wrote:
Jacob Rief [EMAIL PROTECTED] writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating environment is C not C++. If you dumb it down enough
--- no exceptions, no RTTI, no use of C++
On 2/14/07, Hannu Krosing [EMAIL PROTECTED] wrote:
OTOH, for same page HOT tuples, we have the command and trx ids stored
twice first as cmax,xmax of the old tuple and as cmin,xmin of the
updated tuple. One of these could probably be used for in-page HOT tuple
pointer.
I think we recently
Florian G. Pflug wrote:
Andreas Pflug wrote:
Tom Lane wrote:
Jacob Rief [EMAIL PROTECTED] writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating environment is C not C++. If you dumb it down enough
--- no
So to implement the agreed upon plan I see the following items.
1) Replace the VARATT_SIZEP macro with SET_VARLENA_LEN. I intend to keep this
patch separate as it will bitrot quickly and would be best if it could be
applied as soon as possible even before the main patch is committed.
I
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, T, 2007-02-13 kell 09:38, kirjutas Tom Lane:
It's all moot anyway since 8 bits isn't enough for a pointer ...
With 8k pages and MAXALIGN=8 we just barely can, as with current page
structure (tuple headers together with data) the
Tom Dunstan [EMAIL PROTECTED] writes:
The enum patch [1] does exactly this with an ANYENUM pseudo-type. It
should provide a pretty good overview of what will be required.
ANYENUM? What's the use-case for that? These special cases in the
type system are enough of a pain-in-the-neck for the
Tom Lane wrote:
Tom Dunstan [EMAIL PROTECTED] writes:
The enum patch [1] does exactly this with an ANYENUM pseudo-type. It
should provide a pretty good overview of what will be required.
ANYENUM? What's the use-case for that? These special cases in the
type system are enough of a
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Andreas Pflug wrote:
Tom Lane wrote:
Jacob Rief [EMAIL PROTECTED] writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating environment is C not C++. If you dumb it down
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
ANYENUM? What's the use-case for that?
Well ... *somebody* suggested it here ...
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00457.php
Well, in that usage (ie, for enum I/O functions) it's not actually
necessary that the
Pavan Deolasee wrote:
- We need to find a way to handle DEAD root tuples, either convert them
into
stubs or overwrite them with a new version. We can also perform pointer
swinging from the index. Again there are concerns about crash-safety and
concurrent index-scans working properly. We don't
Florian G. Pflug wrote:
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Andreas Pflug wrote:
Tom Lane wrote:
Jacob Rief [EMAIL PROTECTED] writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating environment is C not
Magnus Hagander [EMAIL PROTECTED] writes:
Our docs for the integer datetime option says:
Note also that the integer datetimes
code is newer than the floating-point code, and we still find bugs in it
from time to time.
Is the last sentence about bugs really true anymore? At least the
On Wed, 2007-02-14 at 13:19 -0300, Alvaro Herrera wrote:
Probably stack allocation doesn't matter much, as I think that would be
unwinded by the longjmp call. I don't know a lot about C++, but if
there are allocations in the data area then those would probably not be
freed. But it makes me
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
ANYENUM? What's the use-case for that?
Well ... *somebody* suggested it here ...
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00457.php
Well, in that usage (ie, for enum I/O
On Tue, Feb 13, 2007 at 05:55:11PM -0500, Bruce Momjian wrote:
Is there a TODO here?
---
Jim Nasby wrote:
On Oct 2, 2006, at 6:28 PM, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
However, the test
adding an anyelement2 pseudotype ... The context was a
compatibility SQL function to support Oracle's DECODE function.
The reason it's not in there already is we didn't seem to have quite
enough use-case to justify it. Do you have more?
No. Even this case, for me, is more an expedient
Gregory Stark [EMAIL PROTECTED] writes:
1) Replace the VARATT_SIZEP macro with SET_VARLENA_LEN.
If we're going to do this then it's time to play the name game; that is,
pick names we actually like and that work well together. The original
TOAST patch made things a bit messy in this area. We
On Wed, Feb 14, 2007 at 11:27:31AM -0500, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Our docs for the integer datetime option says:
Note also that the integer datetimes
code is newer than the floating-point code, and we still find bugs in it
from time to time.
Is the
Heikki Linnakangas [EMAIL PROTECTED] writes:
What's the verdict on relaxing the live tuple's ctid doesn't change
rule?
I think that's unacceptable; it is known that that will break the ODBC
and JDBC drivers, as well as any other programs that make use of the
ctid for re-finding a tuple they
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Andreas Pflug wrote:
Tom Lane wrote:
Jacob Rief [EMAIL PROTECTED] writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating
Neil Conway wrote:
On Wed, 2007-02-14 at 13:19 -0300, Alvaro Herrera wrote:
Probably stack allocation doesn't matter much, as I think that would be
unwinded by the longjmp call. I don't know a lot about C++, but if
there are allocations in the data area then those would probably not be
freed.
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Our docs for the integer datetime option says:
Note also that the integer datetimes
code is newer than the floating-point code, and we still find bugs in it
from time to time.
Is the last sentence about bugs really true
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
What's the verdict on relaxing the live tuple's ctid doesn't change
rule?
I think that's unacceptable; it is known that that will break the ODBC
and JDBC drivers, as well as any other programs that make use of the
ctid for
On 2/14/07, Tom Lane [EMAIL PROTECTED] wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
What's the verdict on relaxing the live tuple's ctid doesn't change
rule?
I think that's unacceptable; it is known that that will break the ODBC
and JDBC drivers, as well as any other programs that
What's the verdict on relaxing the live tuple's ctid doesn't
change rule? If we did allow that within a page, what would
we need to change?
I already said this, but why would this need to be visible from the
outside ?
A few assumptions:
no back pointers
indexes only point
Florian G. Pflug writes:
Maybe we should create some wiki page or pgfoundry project that collects
all glue code, tipps and tricks that people invented to glue C++ into
the postgres backend.
If it can be made to work, sure; in techdocs.
I was thinking that two pairs of macros,
But now that I think of it, how do we get the root tid of a
tuple? I suppose we'd be back to having backpointers or
scanning the whole page... I guess pointer-swinging it is, then.
During vacuum you see a root [stub] not recently dead. You follow
the chain to detect if you find a live
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
ANYENUM? What's the use-case for that?
Well ... *somebody* suggested it here ...
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00457.php
Well, in that usage (ie, for enum I/O functions) it's not actually
Tom Dunstan [EMAIL PROTECTED] writes:
Regarding the type system understanding ANYENUM, most of the type system
treats ANYENUM identically to ANYELEMENT, the only parts that really
need to understand it are the bits that try to tie down concrete types.
The reason I'm feeling annoyed with
Just to summarize:
o Every tuple gets a heap ctid
o Only the root tuple gets an index entry
o We can easily remove dead tuples that aren't the root because
by definition, nothing points to them, including backends and
indexes
The problem is that
On Tue, 2007-02-13 at 20:01 -0500, Tom Lane wrote:
I would suggest that the search path be added as an explicit parameter
to CREATE FUNCTION, with a default of the current setting. The main
reason for this is that it's going to be a real PITA for pg_dump if we
don't allow an explicit
Gregory Stark wrote:
2) Replace VARATT* macros to store and retrieve the toast bits in a manner
that will work for variable length headers. This either means storing the
bits at the least-significant position or using network byte order.
If we want to allow storing 1 headers
On Wed, Feb 14, 2007 at 01:56:03PM -0500, Bruce Momjian wrote:
Could we insert index tuples for the live tuple and then remove the root
tuple, perhaps later? So basically we break the chain at that time.
The problem there is that we basically have nothing better than what we
have now --- we
I wrote:
Tom Dunstan [EMAIL PROTECTED] writes:
Regarding the type system understanding ANYENUM, most of the type system
treats ANYENUM identically to ANYELEMENT, the only parts that really
need to understand it are the bits that try to tie down concrete types.
The reason I'm feeling
Bruce Momjian [EMAIL PROTECTED] writes:
Gregory Stark wrote:
If we want to allow storing 1 headers unaligned which I think would be
good then I still think we have to read them using bytewise lookups -- ie
by casting to (char*). That means network byte order or using the low order
bits is
On Tue, 13 Feb 2007, Marc Munro wrote:
On Mon, 2007-12-02 at 00:10 -0500, Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
Consider a table C containing 2 child records C1 and C2, of parent P.
If transaction T1 updates C1 and C2, the locking order of the the
records will be C1, P,
On Wed, Feb 14, 2007 at 12:38:12PM -0500, Andrew Dunstan wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Our docs for the integer datetime option says:
Note also that the integer datetimes
code is newer than the floating-point code, and we still find bugs in it
from time
Added to TODO:
o Use LC_TIME for localized weekday/month names, rather than
LC_MESSAGES
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00390.php
---
Euler Taveira de Oliveira wrote:
sponge failed the XML regression test once today:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spongedt=2007-02-14%2007:30:02
If i read that correctly we could just add a simple ORDER BY
table_name to that query to get a more reliable result.
Stefan
---(end
Zeugswetter Andreas ADI SD wrote:
A few assumptions:
no back pointers
indexes only point at slots marked as roots (and non hot tuples)
During vacuum, you swap the tuples and keep a stub at the slot that the
user's ctid might be pointing at. You mark the stub to detect this
Andreas,
Have you considered hardcoding the schema for each object where it was
found at creation time ? This seems more intuitive to me.
This isn't practical. Consider the schema qualification syntax for
operators.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
Tom Lane [EMAIL PROTECTED] writes:
Plus you can't do it without multiple evaluation of the macro argument,
which is something I'd really prefer we not introduce into such a
widely-used macro.
I don't see any way to do VARSIZE without multiply evaluating its argument.
It's got to mask out the
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Plus you can't do it without multiple evaluation of the macro argument,
I don't see any way to do VARSIZE without multiply evaluating its argument.
Some variant of
#define VARSIZE(x) (ntohl((x)-vl_len)
On Tue, Feb 13, 2007 at 01:32:11PM -0500, Bruce Momjian wrote:
Gregory Stark wrote:
Alternatively, what does the trailing a in varlena signify? Would this be
varlenb?
attribute
--
Actually varlena stands for variable length array.
elein
[EMAIL PROTECTED]
I want to register, just in principle, that I object to changing
the structure of a varlena.
The idea behind the data type is simple, clean and fast. And it is
easily understood by developers and by people developing applications
and functions in PostgreSQL.
Of course you will do what you
elein [EMAIL PROTECTED] writes:
I want to register, just in principle, that I object to changing
the structure of a varlena.
Indeed, I'm doing my best to restrain Greg from changing what a
datatype-specific function will see by default. The stuff with
variable-length headers should be
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
sponge failed the XML regression test once today:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spongedt=2007-02-14%2007:30:02
If i read that correctly we could just add a simple ORDER BY
table_name to that query to get a more reliable
55 matches
Mail list logo
