Ü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
> 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 wa
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 pat
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). N
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
shoul
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 t
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
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
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) t
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 p
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 eno
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 tha
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 ha
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 backe
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 bu
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 m
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 functi
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:
> > >> Ho
> > 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 expe
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.
>
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 th
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 envi
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 an
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 re-fin
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 t
> 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 poi
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 tu
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 a
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 speci
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 un
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 ---
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 feel
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
>>
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 w
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 i
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:
> P
sponge failed the XML regression test once today:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sponge&dt=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
situat
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 o
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)->
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 wi
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 con
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> sponge failed the XML regression test once today:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sponge&dt=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 rel
55 matches
Mail list logo