-- Best,Gourish Singbal
On Wed, Jul 05, 2006 at 09:14:21PM -0400, Greg Stark wrote:
> Well what was tripping me up was figuring out the operator class. I just
> realized it's in the index's Relation object.
>
> But yes what you describe is really a problem. Even given the operator class
> there's no way for me to know w
Greg Stark <[EMAIL PROTECTED]> writes:
> I'm a bit confused about how scan keys work. Is there any simple way given a
> list of Datums of the same type as the index tuple attributes to get all
> matching index entries? This is for a non-system index.
Define "matching".
> I tried just using index_
On Wed, Jul 05, 2006 at 05:57:08PM -0700, Joshua D. Drake wrote:
>
> > I am well aware of what security definer means. The significant part of
> > this example is that lastval() will allow the caller to see the value of
> > a sequence where currval('seq') will not. This means that things which
> >
On Thu, Jun 29, 2006 at 06:47:17PM +0200, Martijn van Oosterhout wrote:
> It seems to me that maybe the backend should include a 16-byte fixed
> length object (after all, we've got 1, 2, 4 and 8 bytes already) and
> then people can use that to build whatever they like, using domains,
> for example.
On Thu, Jul 06, 2006 at 12:12:18PM -0400, [EMAIL PROTECTED] wrote:
> Please answer the below questions, and state whether your opinion is
> just an opinion, or whether you are stating it as a PostgreSQL
> maintainer and it is law. If you wish, you can rank preferences.
Do I have to pick only one?
On 7/6/06, [EMAIL PROTECTED] wrote:
Please answer the below questions, and state whether your opinion is
just an opinion, or whether you are stating it as a PostgreSQL
maintainer and it is law. If you wish, you can rank preferences.
1) The added 128-bit type should take the form of:
a) UUI
I looked around in the code and the whole thing looks complex
and prone to breaking my code often, i.e., whenever someone will decide to
change the casting/operators. I thought about just
issuing in SPI_prepare query the proper casting like:
SELECT a0::text,a1::text ...
Casting to equal types (whe
Tom Lane <[EMAIL PROTECTED]> writes:
> > I tried just using index_getprocinfo(...,BTORDER) with InvalidStrategy like
> > btree does but _bt_preprocess_keys runs into problems without a valid
> > strategy
> > number. And in any case that would be btree specific which seems like it
> > ought
> > n
[EMAIL PROTECTED] writes:
> e) Generic n-byte binary data type generator. Not sure of feasibility
>of this at this point. See thread.
I don't like the idea of a generator that would have to be manually invoked,
though such a thing would be a fine tool for contrib or pgfoundry, I think
Hi,
Just MHO:
1) The added 128-bit type should take the form of:
c) UUID, with only encode/decode/indexable - generic except for the
name of the type, and the encoding format.
2) According to your answer in 1), the added 128-bit type should be:
a) In core first.
1c is what I wo
On Thu, Jul 06, 2006 at 07:43:20PM +0300, Tzahi Fadida wrote:
> The downside is that i noticed that the CTID is removed from the tuple
> if a cast occurs. Is there a way to tell postgresql to not remove the
> CTID?
Err, the fact the ctid is removed is really just a side-effect. With no
adjusting o
On Thursday 06 July 2006 21:55, Martijn van Oosterhout wrote:
> On Thu, Jul 06, 2006 at 07:43:20PM +0300, Tzahi Fadida wrote:
> > The downside is that i noticed that the CTID is removed from the tuple
> > if a cast occurs. Is there a way to tell postgresql to not remove the
> > CTID?
>
> Err, the f
Greg Stark wrote:
In answer to your question, though my opinion carries no special weight at
all, I would suggest adding a bare bones 16-byte data type to core and a
second binary-compatible data type based on it that parsed/output as uuids.
The extended uuid libraries should only go in pgfoundr
Greg Stark <[EMAIL PROTECTED]> writes:
> But on that note, is it ok to use the bulkdelete index AM methods for
> non-vacuum purposes
Um, what would those be?
ambulkdelete and amvacuumcleanup are most certainly not designed to be
used in any context other than VACUUM. You might be able to abuse t
Per tonight's dinner discussion, it Sure Would Be Nice if psql had an
additional option that allowed passing in a conninfo string.
The notion: Plenty of libraries out there like Pg, DBI::Pg, and such
make you specify connections in the form:
"host=my.db.host.example.org port=5678 dbname=dumb_d
I've worked on a prototype (attached to this email) of the SRF function and I can query the xlog files for some useful info.I know that the error codes are still incorrect and the tests are missing, but this is only a proof of concept.
Examples of usage:Query for committed transactions on the xlog
18 matches
Mail list logo
