On Sun, Jan 10, 2010 at 07:16:59PM +0100, Boszormenyi Zoltan wrote:
> As would ecpg_dynamic_type(), then. :-(
My guess is that this function is fine when returning InvalidOid = 0. AFAICT it
is supposed to fill an integer with the SQL3 type code which seems to start
with 1 too. So I will change thi
2010/1/13 Boszormenyi Zoltan :
> Tom Lane írta:
>>
>> If this patch is touching those parts of relcache.c, it probably needs
>> rethinking.
>>
>
> What I did there is to check the return value of LockRelationOid()
the hunk was because a diference in the position (i guess patch accept
a hunk of rea
Tom Lane írta:
> Jaime Casanova writes:
>
>> it has a hunk failed when trying to apply i guess it's because of
>> Tom's refactor of relcache.c
>>
>
> If this patch is touching those parts of relcache.c, it probably needs
> rethinking.
>
> regards, tom lane
>
>
The
"J. Greg Davidson" writes:
> (4) In conclusion, I hope that PostgreSQL will keep xml2
> or something similar even when the XSLT and speculative parsing
> issues have been addressed.
Are you sufficiently excited about it to fix its memory management
issues?
http://archives.postgresql.org/message-i
On Tue, Jan 12, 2010 at 10:16 AM, Bruce Momjian wrote:
> I am concerned that knowledge of this new read-only replication user
> would have to be spread all over the backend code, which is really not
> something we should be doing at this stage in 8.5 development. I am
> also thinking such a speci
Jaime Casanova writes:
> it has a hunk failed when trying to apply i guess it's because of
> Tom's refactor of relcache.c
If this patch is touching those parts of relcache.c, it probably needs
rethinking.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-h
On Tue, Jan 12, 2010 at 10:59 PM, Tom Lane wrote:
> Fujii Masao writes:
>> I'm not sure whether poll(2) should be called for this purpose. But
>> poll(2) and select(2) seem to often come together in the existing code.
>> We should follow such custom?
>
> Yes. poll() is usually more efficient, so
Simon Riggs wrote:
> On Tue, 2010-01-12 at 15:42 -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > The final commit-fest is in 5 days --- this is not the time for design
> > > discussion and feature additions.
> >
> > +10 --- the one reason I can see for deciding to bounce SR is that there
>
> So it seems to me that the threshold question for this patch is - do
> we think it's a good idea to maintain two implementations of PL/python
> in core?
Not really, no. This is why we need PGAN ;-)
If the new implementation is *better* that the existing PL/python, I
could see eventually repla
> However, it's probably a better thing to simply expose a way to query
> how much extra log data we have, in raw form (bytes or pages). From
> this, an administration script could take appropriate action.
Also: I think we could release without having this facility. We did
with PITR, after all
> I guess the slightly more ambitious performance monitoring bits that
> Simon was suggesting may cross the line as being too late to implement
> now though (depends on how productive the people actually coding on this
> are I guess), and certainly the ideas thrown out for implementing any
> smart
On Sun, Dec 13, 2009 at 5:02 PM, James Pye wrote:
> On Nov 19, 2009, at 5:41 PM, James Pye wrote:
>> Here's my latest patch.
>
> Fixed a lot of memory/reference leaks, added some minor features(mostly
> around Arrays), and filled in more documentation.
>
> At this point, I don't have any more min
Reporting as requested, there are two things our projects
continue to need xml2 for, and a third which we conceptually
need xml2 for:
(1) We need some way to do xslt processing.
(2) We need the equivalent of xml_is_well_formed(text), e.g.
a documented way to call XMLPARSE speculatively and get a
On Tuesday 12 January 2010 17:37:11 Simon Riggs wrote:
> There is not much sense being talked here. I have asked for sufficient
> monitoring to allow us to manage it in production, which is IMHO the
> minimum required to make it shippable. This is a point I have mentioned
> over the course of many
On Monday 11 January 2010 23:24:24 Greg Smith wrote:
> Fujii Masao wrote:
> > On Mon, Jan 11, 2010 at 5:36 PM, Craig Ringer
> >
> > wrote:
> >> Personally, I'd be uncomfortable enabling something like that without
> >> _both_ an admin alert _and_ the ability to refresh the slave's base
> >> backup
Greg Smith escreveu:
> pg_stat_reset( which text )
> which := 'buffers' | 'checkpoints' | 'tables' | 'functions' | ...
>
What about adding 'all' too? Or the idea is resetting all global counters when
we call pg_stat_reset() (without parameters)?
--
Euler Taveira de Oliveira
http://ww
2010/1/12 Hans-Jürgen Schönig :
> hi,
>
> this patch implements SQL side tracing / tracking of statements and
> statement execution times.
>
why is this better than using the "auto explain" module?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de siste
On Sun, Jan 10, 2010 at 4:35 PM, Robert Haas wrote:
>>> I would strongly suggest to Tim that he rip the portions of this patch
>>> that are related to this feature out and submit them separately so
>>> that we can commit the uncontroversial portions first.
>>
>> See my previous email. I suggested
Tom Lane wrote:
"Kevin Grittner" writes:
>> It's obviously too low level to be the right place to check
>> whether we're in serializable mode and take out locks, but if I
>> look at the callers (like IndexNext or TidNext) which use a valid
>> buffer in a call to ExecStoreTuple, should I be catc
"Kevin Grittner" writes:
> Hopefully this won't digress into a top-to-bottom discussion of all
> aspects of implementing serializable transactions again, but I have
> what I hope is a quick question.
> The "easy" part of implementing SIREAD level predicate locking
> should be to get a lock on ea
On Tue, 2010-01-12 at 19:43 +0100, Andres Freund wrote:
> On Tuesday 12 January 2010 09:40:03 Simon Riggs wrote:
> > On Tue, 2010-01-12 at 06:30 +0100, Andres Freund wrote:
> > > Currently the patch does not yet do anything to avoid letting the
> > > protocol out of sync. What do you think about ad
Hopefully this won't digress into a top-to-bottom discussion of all
aspects of implementing serializable transactions again, but I have
what I hope is a quick question.
The "easy" part of implementing SIREAD level predicate locking
should be to get a lock on each visible tuple which is read in th
Stefan Kaltenbrunner wrote:
> The database needs to prove very basic information like "we are
> 10min behind in replication" or "3 wal files behind" - the
> decision if any of that is an actual issue or not should be left
> to the actual monitoring system.
+1
-Kevin
--
Sent via pgsql-hacke
Greg Smith wrote:
Bruce Momjian wrote:
Right, so what is the risk of shipping without any fancy monitoring?
You can monitor the code right now by watching the output shown in the
ps display and by trolling the database logs. If I had to I could build
a whole monitoring system out of thos
On Tue, 2010-01-12 at 17:41 -0500, Greg Smith wrote:
> Bruce Momjian wrote:
> > Right, so what is the risk of shipping without any fancy monitoring?
> >
>
> You can monitor the code right now by watching the output shown in the
> ps display and by trolling the database logs. If I had to I cou
Bruce Momjian wrote:
Right, so what is the risk of shipping without any fancy monitoring?
You can monitor the code right now by watching the output shown in the
ps display and by trolling the database logs. If I had to I could build
a whole monitoring system out of those components, it wo
On Tue, 2010-01-12 at 15:42 -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > The final commit-fest is in 5 days --- this is not the time for design
> > discussion and feature additions.
>
> +10 --- the one reason I can see for deciding to bounce SR is that there
> still seem to be design discus
> Right, so what is the risk of shipping without any fancy monitoring?
We add monitoring in 9.1. er, 8.6.
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Aidan Van Dyk writes:
>> aox has that either as a bulk importer or as a MDA.
>
> Yup, LMTP is ideally suited for that too.
Yes.
>> > 3) A nice set of SQL queries to return message, parts, threads,
>> >folders based on $criteria (search, id, folder, etc)
>>
>> I guess Matteo's working on tha
On Tue, 2010-01-12 at 16:34 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > The final commit-fest is in 5 days --- this is not the time for design
> > > discussion and feature additions.
> >
> > +10 --- the one reason I can see for deciding to bounce SR is that there
Stefan Kaltenbrunner wrote:
> >> Let's get a reasonable feature set implemented and then come back in 8.6
> >> to improve it. For example, there is no need for a special
> >> 'replication' user (just use super-user), and monitoring should be
> >> minimal until we have field experience of exactly w
Arie Bikker wrote:
Peter Eisentraut wrote:
On ons, 2010-01-06 at 23:46 +0100, Arie Bikker wrote:
Hope this is the right attachement type (I'm new at this)
BTW. here a some nice examples:
- Get the number of attributes of the first childnode:
select ( xpath('count(@*)',(xpath('*[1]','g="j"/>
Tom Lane wrote:
> Bruce Momjian writes:
> > The final commit-fest is in 5 days --- this is not the time for design
> > discussion and feature additions.
>
> +10 --- the one reason I can see for deciding to bounce SR is that there
> still seem to be design discussions going on. It is WAY TOO LATE
* Dimitri Fontaine [100112 16:28]:
> > 1) A nice normalized DB schema representing mail messages and their
> >relations to other message and "recipients" (or "folders")
>
> We're now hoping that this one will fit:
>
> http://www.archiveopteryx.org/schema
Yup, and it provides a lot more t
Aidan Van Dyk writes:
> I'll note that the whole idea of a "email archive" interface might be a
> very good "advocacy" project as well. AOX might not be a perfect fit,
> but it could be a good learning experience... Really, all the PG mail
> archives need is:
>
> 1) A nice normalized DB schema r
Hi,
The thought was that it might be helpful to be able to raise NOTICE or DEBUG*
as well - but admitedly there is not a big need for it...
Andres
--
Sent from a mobile phone - please excuse brevity and formatting.
- Ursprüngliche Mitteilung -
> Andres Freund writes:
> > On Tuesday 12 J
Simon Riggs wrote:
On Tue, 2010-01-12 at 15:11 -0500, Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
Simon Riggs wrote:
On Tue, 2010-01-12 at 08:24 +0100, Stefan Kaltenbrunner wrote:
Fujii Masao wrote:
On Tue, Jan 12, 2010 at 1:21 PM, Greg Smith wrote:
I don't think anybody can deploy th
On Tue, 2010-01-12 at 15:11 -0500, Bruce Momjian wrote:
> Stefan Kaltenbrunner wrote:
> > Simon Riggs wrote:
> > > On Tue, 2010-01-12 at 08:24 +0100, Stefan Kaltenbrunner wrote:
> > >> Fujii Masao wrote:
> > >>> On Tue, Jan 12, 2010 at 1:21 PM, Greg Smith
> > >>> wrote:
> > I don't think any
Bruce Momjian writes:
> The final commit-fest is in 5 days --- this is not the time for design
> discussion and feature additions.
+10 --- the one reason I can see for deciding to bounce SR is that there
still seem to be design discussions going on. It is WAY TOO LATE for
that folks. It's time
Marko Kreen writes:
> FYI: on PL/Proxy we use poll() exclusively and on platforms
> that dont have it (win32) we emulate poll() with select():
Yeah, maybe. At the time we started adding poll() support there were
enough platforms with only select() that it didn't make sense to impose
any sort of
On Tue, Jan 12, 2010 at 3:11 PM, Bruce Momjian wrote:
> The final commit-fest is in 5 days --- this is not the time for design
Actually just over 2 days at this point...
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
Il 12/01/2010 21:04, Magnus Hagander ha scritto:
On Tue, Jan 12, 2010 at 20:56, Matteo Beccati wrote:
Il 12/01/2010 10:30, Magnus Hagander ha scritto:
The problem is usually with strange looking emails with 15 different
MIME types. If we can figure out the proper way to render that, the
rest
I'll note that the whole idea of a "email archive" interface might be a
very good "advocacy" project as well. AOX might not be a perfect fit,
but it could be a good learning experience... Really, all the PG mail
archives need is:
1) A nice normalized DB schema representing mail messages and thei
Stefan Kaltenbrunner wrote:
> Simon Riggs wrote:
> > On Tue, 2010-01-12 at 08:24 +0100, Stefan Kaltenbrunner wrote:
> >> Fujii Masao wrote:
> >>> On Tue, Jan 12, 2010 at 1:21 PM, Greg Smith wrote:
> I don't think anybody can deploy this feature without at least some very
> basic monitori
On 1/12/10, Tom Lane wrote:
> Fujii Masao writes:
> > I'm not sure whether poll(2) should be called for this purpose. But
> > poll(2) and select(2) seem to often come together in the existing code.
> > We should follow such custom?
>
>
> Yes. poll() is usually more efficient, so it's preferre
On Tue, Jan 12, 2010 at 20:56, Matteo Beccati wrote:
> Il 12/01/2010 10:30, Magnus Hagander ha scritto:
>>
>> The problem is usually with strange looking emails with 15 different
>> MIME types. If we can figure out the proper way to render that, the
>> rest really is just a SMOP.
>
> Yeah, I was e
Il 12/01/2010 19:54, Magnus Hagander ha scritto:
On Tue, Jan 12, 2010 at 18:34, Dave Page wrote:
On Tue, Jan 12, 2010 at 10:24 PM, Tom Lane wrote:
"Joshua D. Drake" writes:
On Tue, 2010-01-12 at 10:24 +0530, Dave Page wrote:
So just to put this into perspective and give anyone paying atten
Il 12/01/2010 10:30, Magnus Hagander ha scritto:
The problem is usually with strange looking emails with 15 different
MIME types. If we can figure out the proper way to render that, the
rest really is just a SMOP.
Yeah, I was expecting some, but all the message I've looked at seemed to
be work
Changes:
- split patch to several ones
- sync with current CVS
Patch set is based on 0.5.1 version, difference between 0.5 and 0.6 should be
only in planner patch.
builtin_knngist_itself-0.6.gz - patch to the gist itself
builtin_knngist_proc-0.6.gz - patch for support knnsearch in point_ops
Andres Freund writes:
> On Tuesday 12 January 2010 09:40:03 Simon Riggs wrote:
>>> So that one could do an elog(ERROR & ERROR_NO_SEND_CLIENT, .. or such?
> Do you aggree on the approach then? Do you want to do it?
Why not use the already-existing COMMERROR thing?
regard
On Tue, Jan 12, 2010 at 18:34, Dave Page wrote:
> On Tue, Jan 12, 2010 at 10:24 PM, Tom Lane wrote:
>> "Joshua D. Drake" writes:
>>> On Tue, 2010-01-12 at 10:24 +0530, Dave Page wrote:
So just to put this into perspective and give anyone paying attention
an idea of the pain that lies a
Simon Riggs wrote:
On Tue, 2010-01-12 at 08:24 +0100, Stefan Kaltenbrunner wrote:
Fujii Masao wrote:
On Tue, Jan 12, 2010 at 1:21 PM, Greg Smith wrote:
I don't think anybody can deploy this feature without at least some very
basic monitoring here. I like the basic proposal you made back in S
Magnus Hagander wrote:
I have on my TODO to implement the ability to do stats reset on a
single object (say, one table only). Please take this into
consideration when you design/name this, so theres no unnecessary
overlap :-) Same goes for the stats message itself.
The idea suggested upthrea
On Tuesday 12 January 2010 09:40:03 Simon Riggs wrote:
> On Tue, 2010-01-12 at 06:30 +0100, Andres Freund wrote:
> > Currently the patch does not yet do anything to avoid letting the
> > protocol out of sync. What do you think about adding a flag for error
> > codes not to communicate with the clie
On Tue, Jan 12, 2010 at 17:58, Fujii Masao wrote:
> On Tue, Dec 22, 2009 at 8:49 PM, Heikki Linnakangas
> wrote:
>>> Umm.., I still cannot find the place where the walreceiver module is
>>> loaded by using load_external_function() in your 'replication' branch.
>>> Also the compilation of that bra
Robert Haas writes:
> On Tue, Jan 12, 2010 at 4:19 AM, Dimitri Fontaine
> wrote:
>> You sound like you want to drop the last Commit Fest and prepare beta
>> instead.
> I think I was pretty clear about what I was proposing in the message
> with which I started this thread - bump some or all the b
Robert Haas writes:
> I feel like we ought to be doing this in a way where the output is
> properly escaped.
This is one of several reasons why code shouldn't be trying to scrape
the names out of the human-readable message.
regards, tom lane
--
Sent via pgsql-hackers ma
Robert Haas writes:
> Tom made some changes for 8.5 that will result in materialization
> being used in more places, and I think we're seeing that here. The
> planner thinks that materializing the inner side of the nestloop will
> save it from going to disk for every iteration, but that's not rea
On Tue, Jan 12, 2010 at 3:08 AM, Pavel Stehule wrote:
> 2010/1/12 Matteo Beccati :
>> Il 12/01/2010 08:55, Pavel Stehule ha scritto:
>>>
>>> I checked query and I was surprised with very strange plan:
>>>
>>> postgres=# explain select a, b from a,b,c;
>>> QUERY PLAN
"Joshua D. Drake" wrote:
> On Tue, 2010-01-12 at 12:52 -0500, Robert Haas wrote:
>> I think I was pretty clear about what I was proposing in the
>> message with which I started this thread - bump some or all the
>> big, outstanding patches to leave more time for stabilizing the
>> tree.
>>
>> A
Robert Haas wrote:
> On Tue, Jan 12, 2010 at 4:19 AM, Dimitri Fontaine
> wrote:
> > Robert Haas writes:
> >> I agree. ?My main concern in terms of dealing with these outstanding
> >> is that it will distract us, particularly Tom, from stabilizing the
> >> tree, especially HS, VF, and SR. ?If the
On 01/12/2010 06:43 AM, Andrew Chernow wrote:
>>
>> What is the point of this discussion? We're not going to remove the
>> facility for composite types, regardless of whether or not some people
>> regard them as unnecessary. And "a name that better suits the task" is
>> not to be sneered at anyway.
Robert Haas wrote:
> I feel like we ought to be doing this in a way where the output is
> properly escaped. Right now:
Yeah, that's been an occasional irritation for me, even though I
don't actually use quote characters in any of my quoted identifiers.
Also, tab-completion is irritating in no
On Tue, 2010-01-12 at 12:52 -0500, Robert Haas wrote:
> On Tue, Jan 12, 2010 at 4:19 AM, Dimitri Fontaine
> wrote:
> > Robert Haas writes:
> >> I agree. My main concern in terms of dealing with these outstanding
> >> is that it will distract us, particularly Tom, from stabilizing the
> >> tree,
On Tue, Jan 12, 2010 at 4:19 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I agree. My main concern in terms of dealing with these outstanding
>> is that it will distract us, particularly Tom, from stabilizing the
>> tree, especially HS, VF, and SR. If the tree were in a releasable
>> st
On Tue, Jan 12, 2010 at 5:10 AM, Takahiro Itagaki
wrote:
> Andreas Joseph Krogh wrote:
>
>> ERROR: null value in column "created" violates not-null constraint
>
> It is easy to add the table name to the message, but ...
>
>> ERROR: null value in column "public"."mytable"."created" violates not-nu
On Tue, Jan 12, 2010 at 10:24 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> On Tue, 2010-01-12 at 10:24 +0530, Dave Page wrote:
>>> So just to put this into perspective and give anyone paying attention
>>> an idea of the pain that lies ahead should they decide to work on
>>> this:
>>>
>>> -
On 01/11/2010 07:43 PM, Takahiro Itagaki wrote:
> There is a memory leak in dblink when we cancel a query during
> returning tuples. It could leak a PGresult because memory used
> by it is not palloc'ed one. I wrote a patch[1] before, but I've
> badly used global variables to track the resource.
>
On Tue, 2010-01-12 at 11:54 -0500, Tom Lane wrote:
> > Or, we just leave the current infrastructure in place and use a new one
> > for all new messages going forward. We shouldn't limit our ability to
> > have a decent system due to decisions of the past.
>
> -1. What's the point of having archi
On Tue, Dec 22, 2009 at 8:49 PM, Heikki Linnakangas
wrote:
>> Umm.., I still cannot find the place where the walreceiver module is
>> loaded by using load_external_function() in your 'replication' branch.
>> Also the compilation of that branch fails. Is the 'pushed' branch the
>> latest? Sorry if
"Joshua D. Drake" writes:
> On Tue, 2010-01-12 at 10:24 +0530, Dave Page wrote:
>> So just to put this into perspective and give anyone paying attention
>> an idea of the pain that lies ahead should they decide to work on
>> this:
>>
>> - We need to import the old archives (of which there are hun
I wrote:
> git status | grep '^#[^ ]' | sed -e 's/#\t//' \
> -e '/^[^\/][^\/]*$/ s/^/\//' >> .gitignore
I guess that part can be simplified to:
git status | grep '^#[^ ]' | sed -e 's/#\t/\//' >> .gitignore
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Tue, 2010-01-12 at 10:24 +0530, Dave Page wrote:
> 2010/1/12 Matteo Beccati :
> > So, I've decided to spend a bit more time on this and here is a proof of
> > concept web app that displays mailing list archives reading from the AOX
> > database:
> >
> > http://archives.beccati.org/
>
> Seems
Robert Haas wrote:
> What I'm interested in is being able to run 'git status' on a tree
> in which I've run a build without getting a lot of extra output,
> and that will require ignoring all the build products.
If you prefer to keep it all in one directory tree, something like
the following w
On tis, 2010-01-12 at 09:54 -0500, Merlin Moncure wrote:
> *) should 'create type as' get an 'alter'? ( I think most would think so)
Working on that right now ...
> *) if so, how do you distinguish between the composite and non
> composite version? How would this command look?
I'm only dealing
Pavel Stehule writes:
> it doesn't support EXPLAIN as possible begin of SQL statement:
> postgres=# create or replace function foo(_a int) returns void as
> $$declare s varchar; begin for s in explain select * from omega where
> a = _a loop raise notice '%', s; end loop; return; end; $$ language
On Tue, Jan 12, 2010 at 15:59, Tom Lane wrote:
> Magnus Hagander writes:
>> Sorry if this is talking about something completely different, haven't
>> followed the thread closely, but: will this change the output of
>> pg_restore -l? If so, changing the tag is likely to break scripts, and
>> IMHO
Magnus Hagander writes:
> Sorry if this is talking about something completely different, haven't
> followed the thread closely, but: will this change the output of
> pg_restore -l? If so, changing the tag is likely to break scripts, and
> IMHO should be avoided if possible.
Only to the extent of
On Tue, Jan 12, 2010 at 9:00 AM, Andrew Dunstan wrote:
> What is the point of this discussion? We're not going to remove the facility
> for composite types, regardless of whether or not some people regard them as
> unnecessary. And "a name that better suits the task" is not to be sneered at
> anyw
On Tue, Jan 12, 2010 at 15:44, Tom Lane wrote:
> Peter Eisentraut writes:
>> On mån, 2010-01-11 at 12:54 -0500, Tom Lane wrote:
>>> -- Name: binary_coercible(oid, oid); Type: FUNCTION; Schema: public; Owner:
>>> postgres
>
>> Um, that tag is the "name", and if you change that, the name in CREATE
Peter Eisentraut writes:
> On mån, 2010-01-11 at 12:54 -0500, Tom Lane wrote:
>> -- Name: binary_coercible(oid, oid); Type: FUNCTION; Schema: public; Owner:
>> postgres
> Um, that tag is the "name", and if you change that, the name in CREATE
> FUNCTION also changes.
So?
> In the mean time, ha
What is the point of this discussion? We're not going to remove the
facility for composite types, regardless of whether or not some people
regard them as unnecessary. And "a name that better suits the task" is
not to be sneered at anyway.
I never asked for anything to be removed nor do I s
Magnus Hagander writes:
> On Tue, Jan 12, 2010 at 08:22, Heikki Linnakangas
> wrote:
>> Maybe we should just change the existing pg_current_xlog_location()
>> function to return that when recovery is in progress. It currently
>> throws an error during hot standby.
> Not sure. I don't really like
Peter Eisentraut wrote:
On tis, 2010-01-12 at 08:05 -0500, Andrew Chernow wrote:
In practice, tables can be used for passing data around or storing it on disk.
So, I guess my question remains unanswered as to what the composite type offers
that a table doesn't; other than a name that better sui
On mån, 2010-01-11 at 12:54 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On mån, 2010-01-11 at 10:44 -0500, Tom Lane wrote:
> >> I think you could probably use the existing tag field; no need for a new
> >> one.
>
> > Sorry, which tag field are you referring to?
>
> The one called "tag"
Takahiro Itagaki writes:
> Do we have any guideline about the message for identifier names?
The issue has come up before. I think that what we really need here is
to implement additional fields in error message reports, so that the
name and schema name of the relevant object can be pulled out of
Tom Lane írta:
> Alvaro Herrera writes:
>
>> But it would be broken in very obvious ways, no? It's not like it would
>> be silently broken and thus escape testing ...
>>
>
> Well, if we wanted to adopt that approach, we should add the count to
> *all* SELECT tags not just a small subset.
On Tue, Jan 12, 2010 at 15:13, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>
>> Fujii Masao writes:
>>
>>>
>>> I'm not sure whether poll(2) should be called for this purpose. But
>>> poll(2) and select(2) seem to often come together in the existing code.
>>> We should follow such custom?
>>>
>>
Tom Lane wrote:
Fujii Masao writes:
I'm not sure whether poll(2) should be called for this purpose. But
poll(2) and select(2) seem to often come together in the existing code.
We should follow such custom?
Yes. poll() is usually more efficient, so it's preferred, but not all
platfo
Peter Eisentraut wrote:
On tis, 2010-01-12 at 08:05 -0500, Andrew Chernow wrote:
In practice, tables can be used for passing data around or storing it on disk.
So, I guess my question remains unanswered as to what the composite type offers
that a table doesn't; other than a name that bette
Fujii Masao writes:
> I'm not sure whether poll(2) should be called for this purpose. But
> poll(2) and select(2) seem to often come together in the existing code.
> We should follow such custom?
Yes. poll() is usually more efficient, so it's preferred, but not all
platforms have it. (On the ot
On tis, 2010-01-12 at 08:05 -0500, Andrew Chernow wrote:
> In practice, tables can be used for passing data around or storing it on
> disk.
> So, I guess my question remains unanswered as to what the composite type
> offers
> that a table doesn't; other than a name that better suits the task.
Peter Eisentraut wrote:
On mån, 2010-01-11 at 19:27 -0500, Andrew Chernow wrote:
Peter Eisentraut wrote:
On mån, 2010-01-11 at 15:02 -0500, Andrew Chernow wrote:
ISTM that the ultimate would be a 'create table (_) without storage'
(or some'm) and make 'create type' an alternate syntax for
Thank you very much for refining patch.
I thought there is no missing part.
Magnus Hagander wrote:
> On Fri, Dec 4, 2009 at 11:42, Tsutomu Yamada wrote:
> > The following patches support Windows x64.
> >
> > 1) use intptr_t for Datum and pointer macros. (to support Windows LLP64)
> > almo
On Tuesday 12. January 2010 11.10.09 Takahiro Itagaki wrote:
>
> Andreas Joseph Krogh wrote:
>
> > ERROR: null value in column "created" violates not-null constraint
>
> It is easy to add the table name to the message, but ...
>
> > ERROR: null value in column "public"."mytable"."created" viol
On Tue, Jan 12, 2010 at 08:22, Heikki Linnakangas
wrote:
> Greg Smith wrote:
>> I don't think anybody can deploy this feature without at least some very
>> basic monitoring here. I like the basic proposal you made back in
>> September for adding a pg_standbys_xlog_location to replace what you
>>
On Tue, Jan 12, 2010 at 4:22 PM, Heikki Linnakangas
wrote:
> It would be more straightforward to have a function in the standby to
> return the current replay location. It feels more logical to poll the
> standby to get the status of the standby, instead of indirectly from the
> master. Besides, t
Hello
it doesn't support EXPLAIN as possible begin of SQL statement:
postgres=# create or replace function foo(_a int) returns void as
$$declare s varchar; begin for s in explain select * from omega where
a = _a loop raise notice '%', s; end loop; return; end; $$ language
plpgsql;
CREATE FUNCTION
Andreas Joseph Krogh wrote:
> ERROR: null value in column "created" violates not-null constraint
It is easy to add the table name to the message, but ...
> ERROR: null value in column "public"."mytable"."created" violates not-null
> constraint
> Oracle does this btw...
Do we have any guideli
Hi, I'm reviewing OPEN FOR EXECUTE USING patch and have a couple of
trivial comments.
Pavel Stehule wrote:
> this small patch add missing USING clause to OPEN FOR EXECUTE statement
> + cleaning part of exec_stmt_open function
- Can we use read_sql_expression2() instead of read_sql_construct()
1 - 100 of 115 matches
Mail list logo
