I'm currently adding support for the v3 protocol in PHP pgsql extension.
I'm wondering if anyone minds if I lift documentation wholesale from
the PostgreSQL docs for the PHP docs for these functions. For instance,
the fieldcodes allowed for PQresultErrorField, docs on
PQtransactionStatus, etc
Will PQexecParams automatically escape bytea data as it goes in, or must
one run it through PQescapeBytea first?
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatype
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> This is the key point (say this is point_1) - we must make sure how deep we
> have to go to check validity.
The recorded plan has to somehow mention all the inlined functions that
were expanded out of existence. There might be several levels of such
t
Qingqing Zhou wrote:
I don't quite understand the difference between a SQL function and a
PL/PgSQL function here - since there is a overlapped functionality that we
could implement by SQL function or by PL/PgSQL function.
The difference is between an inlined function (which is integrated
directly
Neil Conway <[EMAIL PROTECTED]> writes:
> Oliver Jowett wrote:
>> Does this mean that clients that use PREPARE/Parse need to handle "plan
>> invalidated" as a possible response to EXECUTE/Bind, or will the backend
>> keep the query string / parse tree around and replan on next execution?
> The l
Neil Conway <[EMAIL PROTECTED]> writes:
> (BTW, another thing to consider is how the rewriter will effect a plan's
> dependencies: I think we should probably invalidate a plan when a
> modification is made to a view or rule that affected the plan.
This issue goes away as long as you follow the r
Tom Lane wrote:
I hadn't really gotten as far as working out a reasonable API for the
module. The $64 question seems to be what is the input: a textual query
string, a raw parse analysis tree, or what?
It should be easy enough to accept either, and then convert from the
query string into a raw pa
Added to TODO list:
* Allow sequential scans to take advantage of other concurrent
sequentiqal scans, also called "Synchronised Scanning"
---
Jeff Davis wrote:
> I had an idea that might improve parallel seqscans on the
"Neil Conway" <[EMAIL PROTECTED]> writes
> I don't see that this is a major problem. If a plan A invokes a function
> B, then changes to B will need to invalidate A; that should be pretty
> easy to arrange. If B is a PL/PgSQL function that invokes a function C,
> it will probably cache a plan invo
Oliver Jowett wrote:
Does this mean that clients that use PREPARE/Parse need to handle "plan
invalidated" as a possible response to EXECUTE/Bind, or will the backend
keep the query string / parse tree around and replan on next execution?
The latter -- the client won't be aware that replanning too
Neil Conway wrote:
- it is the responsibility of the call site managing the prepared plan
to check whether a previously prepared plan is invalid or not -- and to
take the necessary steps to replan it when needed.
Does this mean that clients that use PREPARE/Parse need to handle "plan
invalidated"
Alvaro Herrera wrote:
> On Mon, Mar 14, 2005 at 10:45:51PM -0500, Bruce Momjian wrote:
> > Mark Woodward wrote:
>
> > > Bruce, I did want to meet you to a greater extent, but you we surrounded
> > > by people and looked quite busy.
> >
> > Yea, I was just teasing. It was a very busy conference.
Peter Eisentraut wrote:
> > o Disallow encodings like UTF8 which PostgreSQL supports
> > but the operating system does not (already disallowed by
> > pginstaller)
>
> I think the warning that initdb shouts out is already enough for this.
> I don't think we want to dis
On Mon, Mar 14, 2005 at 10:45:51PM -0500, Bruce Momjian wrote:
> Mark Woodward wrote:
> > Bruce, I did want to meet you to a greater extent, but you we surrounded
> > by people and looked quite busy.
>
> Yea, I was just teasing. It was a very busy conference. I remember at
> night just wanting
Mark Woodward wrote:
> > Christopher Kings-Lynne wrote:
> >> > I really don't intend to do that, and it does seem to happen a lot. I
> >> am
> >> > the first to admit I lack tact, but often times I view the decisions
> >> made
> >> > as rather arbitrary and lacking a larger perspective, but that is
Perhaps it's your lack of a real name and complete anonyminity (hence
invulnerablility) that gets to people...
Is it fixed?
Yeah, hi Mark :)
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
> Christopher Kings-Lynne wrote:
>> > I really don't intend to do that, and it does seem to happen a lot. I
>> am
>> > the first to admit I lack tact, but often times I view the decisions
>> made
>> > as rather arbitrary and lacking a larger perspective, but that is a
>> rant I
>> > don't want to g
Christopher Kings-Lynne wrote:
> > I really don't intend to do that, and it does seem to happen a lot. I am
> > the first to admit I lack tact, but often times I view the decisions made
> > as rather arbitrary and lacking a larger perspective, but that is a rant I
> > don't want to get right now.
>
At 2005-03-14 16:25:22 -0500, [EMAIL PROTECTED] wrote:
>
> > "The file descriptor returned by open is the lowest numbered unused
> > descriptor. [...]
>
> What is meant by "unused?"
Perhaps you should actually look at the standard.
"The open( ) function shall return a file descriptor for the n
I really don't intend to do that, and it does seem to happen a lot. I am
the first to admit I lack tact, but often times I view the decisions made
as rather arbitrary and lacking a larger perspective, but that is a rant I
don't want to get right now.
Perhaps it's your lack of a real name and comple
> [EMAIL PROTECTED] wrote:
>> The point is that this *is* silly, but I am at a loss to understand why
>> it
>> isn't a no-brainer to change. Why is there a fight over a trivial change
>> which will ensure that PostgreSQL aligns to the documented behavior of
>> "open()"
>
> (Why characterise this as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> http://developer.postgresql.org/docs/postgres/catalog-pg-trigger.html
> says "currently unused" and a desultory search through the sources
> confirms that. I imagine it was put there with the intent of adding
> column info later on
Qingqing Zhou wrote:
Second (as Tom says), some changes can hardly be traced. For example, we
only use function A. But function A cites function B, function B cites
function C. when C changes, how do we know that we should worry about our
plan?
I don't see that this is a major problem. If a plan A
On Mon, 2005-03-14 at 20:06 -0500, Bruce Momjian wrote:
> Harald Fuchs wrote:
> > In article <[EMAIL PROTECTED]>,
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >
> > > One possible approach is to do the invalidation on a sufficiently coarse
> > > grain that we don't care. For example, I would be inc
This may be totally irrelevant:
Our current load distributors, like pgpool, have no way of knowing the
side effects of backend functions. It would be interesting if the
client could send each potential query to the master saying, "execute
this query if there are side effects, otherwise do no operat
"Harald Fuchs" <[EMAIL PROTECTED]> writes
> How about using an even coarser grain? Whenever something in the
> database in question changes, blindly throw away all cached plans for
> this DB.
>
If we clearly define what is "something in database in question", we have to
trace all the objects the
Bruce Momjian wrote:
One idea would be to record if the function uses non-temp tables, temp
tables, or both, and invalidate based on the type of table being
invalidated, rather than the table name itself. I can imagine this
hurting temp table caching, but at least functions using regular tables
wo
Harald Fuchs wrote:
> In article <[EMAIL PROTECTED]>,
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > One possible approach is to do the invalidation on a sufficiently coarse
> > grain that we don't care. For example, I would be inclined to make any
> > change in a table's schema invalidate all plan
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> writes:
> One possible approach is to do the invalidation on a sufficiently coarse
> grain that we don't care. For example, I would be inclined to make any
> change in a table's schema invalidate all plans that use that table at
> all;
[EMAIL PROTECTED] wrote:
The point is that this *is* silly, but I am at a loss to understand why it
isn't a no-brainer to change. Why is there a fight over a trivial change
which will ensure that PostgreSQL aligns to the documented behavior of
"open()"
(Why characterise this as a "fight", rather th
> My copy of APUE says on page 49: "The file descriptor returned by open
> is the lowest numbered unused descriptor. This is used by some
> applications to open a new file on standard input, standard output, or
> standard error."
Yes, I'll restate my questions:
What is meant by "unused?" Is it r
[EMAIL PROTECTED] wrote:
>>[EMAIL PROTECTED] writes:
>>
>>
>>>That is hardly anything that I would feel comfortable with. Lets break
>>>this down into all the areas that are ambiguous:
>>>
>>>
>>There isn't anything ambiguous about this, nor is it credible that there
>>are implementati
> [EMAIL PROTECTED] writes:
>> That is hardly anything that I would feel comfortable with. Lets break
>> this down into all the areas that are ambiguous:
>
> There isn't anything ambiguous about this, nor is it credible that there
> are implementations that don't follow the intent of the spec.
How
Bruce Momjian writes:
> Is there no way to create a va_arg va_list structure in C?
Exactly. The standard lets you *read out* from such a structure,
but there's no provision for creating one on-the-fly.
regards, tom lane
---(end of broadcast)-
Tom Lane wrote:
> Bruce Momjian writes:
> > I am wondering if we should just process long long args and %$ args,
> > and pass everything else to the native snprintf.
>
> AFAICS this is a non-starter --- how will you construct the call to
> snprintf? Or even vsnprintf? C doesn't provide the tool
Bruce Momjian writes:
> I am wondering if we should just process long long args and %$ args,
> and pass everything else to the native snprintf.
AFAICS this is a non-starter --- how will you construct the call to
snprintf? Or even vsnprintf? C doesn't provide the tools you need
to make it happen
=?windows-1250?Q?Miroslav_=8Aulc?= <[EMAIL PROTECTED]> writes:
> seriously, I am far below this level of knowledge. But I can contribute
> a test that (maybe) can help. I have rewritten the query so it JOINs the
> varchar() fields (in fact all fields except the IDPK) at the last INNER
> JOIN. Th
Nicolai Tufar wrote:
> On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
> wrote:
> > > The CVS-tip implementation is fundamentally broken and won't work even
> > > for our internal uses. I've not wasted time complaining about it
> > > because I thought we were going to replace it. If we c
Michael Adler <[EMAIL PROTECTED]> writes:
> Our current load distributors, like pgpool, have no way of knowing the
> side effects of backend functions. It would be interesting if the
> client could send each potential query to the master saying, "execute
> this query if there are side effects, oth
=?ISO-8859-2?Q?Miroslav_=A9ulc?= <[EMAIL PROTECTED]> writes:
> [ concerning a deeply nested LEFT JOIN to get data from a star schema ]
> So I have some results. I have tested the query on both PostgreSQL 8.0.1
> and MySQL 4.1.8 with LIMIT set to 30 and OFFSET set to 6000. PostgreSQL
> result is
On Mon, Mar 14, 2005 at 02:53:36AM -0500, Tom Lane wrote:
> Probably the first thing to do is look around at the plausible users of
> this thing and see what they'd find most convenient.
This may be totally irrelevant:
Our current load distributors, like pgpool, have no way of knowing the
side ef
[EMAIL PROTECTED] writes:
> That is hardly anything that I would feel comfortable with. Lets break
> this down into all the areas that are ambiguous:
There isn't anything ambiguous about this, nor is it credible that there
are implementations that don't follow the intent of the spec. Consider
the
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> They are aggregate functions, the avg() is a window aggregate function
> according to the standard. It runs over all values in the same partition.
>
> > -- albeit functions that use data from other records other
> > than the one being output.
>
>
> [EMAIL PROTECTED] writes:
>>> The POSIX spec requires open() to assign fd's consecutively from zero.
>>> http://www.opengroup.org/onlinepubs/007908799/xsh/open.html
>
>> With all due respect, PostgreSQL now runs natively on Win32.
>
> ... using the POSIX APIs that Microsoft so kindly provides.
>
On 14 Mar 2005, Greg Stark wrote:
> > SELECT ROW_NUMBER() OVER bar AS num,
> >x,
> >avg(a) OVER bar,
> >sum (a) OVER bar
> > FROM foo
> > WINDOW bar AS PARTITION BY x ORDER BY x, y, z;
>
> Note that as you said, this returns just as many records as are in the
> original t
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> The standard (sql2003) have what is called windows where one can do these
> things and much more.
OLAP functions would be very nice. But they're not the same thing. In fact
that's precisely *why* they would be really nice. They allow you to do things
=?windows-1250?Q?Miroslav_=8Aulc?= <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Actually, we already had a pending patch (from Atsushi Ogawa) that
>> eliminates that particular O(N^2) behavior in another way. After
>> applying it, I get about a factor-of-4 reduction in the runtime for
>> Miros
[EMAIL PROTECTED] writes:
>> The POSIX spec requires open() to assign fd's consecutively from zero.
>> http://www.opengroup.org/onlinepubs/007908799/xsh/open.html
> With all due respect, PostgreSQL now runs natively on Win32.
... using the POSIX APIs that Microsoft so kindly provides.
fd.c will c
=?windows-1250?Q?Miroslav_=8Aulc?= <[EMAIL PROTECTED]> writes:
> As there are a lot of varchar(1) in the AdDevicesSites table, wouldn't
> be helpful to change them to char(1)? Would it solve the variable-width
> problem at least for some fields and speed the query up?
No, because char(1) isn't p
Ühel kenal päeval (neljapäev, 10. märts 2005, 20:07+0200), kirjutas
Ioannis Theoharis:
>
> Hi,
>
> i have a table:
>
> create table triples(
> att0 varchar(1000),
> att1 int4,
> att2 varchar(20),
> att3 varchar(1000)
> )
>
> My table has 990 raws.
>
> The (possibly wron
On 14 Mar 2005, Greg Stark wrote:
> select distinct on (x) x,y,z
> order by x,y,z
>
> You can do the equivalent:
>
> select x, first(y), first(z)
> order by x,y,z
> group by x
>
> But you can also handle the more general case like:
>
> select x, first(y), first(z), avg(a), sum(s)
> order b
>
>> Maybe we make the assumption that all OS will
>> implement "fd" as an array index
>
> The POSIX spec requires open() to assign fd's consecutively from zero.
> http://www.opengroup.org/onlinepubs/007908799/xsh/open.html
With all due respect, PostgreSQL now runs natively on Win32. Having a
POS
On Fri, 11 Mar 2005 10:37:13 +1300, Mark Kirkwood
<[EMAIL PROTECTED]> wrote:
>Firebird 1.5.1 FreeBSD 5.3
>[correct results]
Interbase 6.0:
SQL> create table tab (col integer);
SQL> select 1 from tab having 1=0;
SQL> select 1 from tab having 1=1;
0<---:-)
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> The case I was thinking of were datatypes without a defined ordering
> where max and min wouldn't be usable. But if GROUP BY was going to
> changed to allow any columns if the primary key was used in the GROUP
> BY clause, I can't see any use for those
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>>> Using libpq PQconnect function, what is the syntax for the 'options'
>>> entry in the conninfo?
>> I think it's stuck straight into the backend command line, so whatever
>> you read in the 'postgres' reference page applies.
> Oh, I thought
Using libpq PQconnect function, what is the syntax for the 'options'
entry in the conninfo?
I think it's stuck straight into the backend command line, so whatever
you read in the 'postgres' reference page applies.
Oh, I thought it was for setting GUCs at connect time. Is that
possible? I though
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> When making PL/Java dynamically adapt to the setting of
> integer-datetimes, I too was bitten by this bug. Is it safe to assume
> that the fix for this will arrive in 8.1.0?
I believe Teodor already committed the change in CVS HEAD.
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Using libpq PQconnect function, what is the syntax for the 'options'
> entry in the conninfo?
I think it's stuck straight into the backend command line, so whatever
you read in the 'postgres' reference page applies.
> I think the docs should
58 matches
Mail list logo
