Interesting. If I define this in C:
int x(int y)
{
char *y;
}
I get a warning:
x.c: In function `x':
x.c:3: warning: declaration of `y' shadows a parameter
but no error. We tend to follow the C conventions, so perhaps we should
throw
I wrote:
> Bruce Momjian writes:
>> It isn't so much the alphabetical order, since there is only one
>> trigger, but the concept that we now group all the _before_ triggers
>> before the _after_ triggers.
> But we've always done that. Has the example ever been correct?
> I was intending to try i
Bruce Momjian writes:
> It isn't so much the alphabetical order, since there is only one
> trigger, but the concept that we now group all the _before_ triggers
> before the _after_ triggers.
But we've always done that. Has the example ever been correct?
I was intending to try it on older version
> The triggers are fired in alphabetical order, check the names of the
> triggers...
It isn't so much the alphabetical order, since there is only one
trigger, but the concept that we now group all the _before_ triggers
before the _after_ triggers. I have updated the sample output to
reflect our
On Wed, Oct 12, 2005 at 07:28:37PM -0400, Tom Lane wrote:
> Oliver Elphick writes:
> > On Wed, 2005-10-12 at 17:45 -0400, Tom Lane wrote:
> >> Hm. Could we see the actual pg_attribute data for both this table and
> >> its parent?
>
> > Here you are:
>
> Thanks. Nothing particularly strange-loo
Oliver Elphick writes:
> On Wed, 2005-10-12 at 17:45 -0400, Tom Lane wrote:
>> Hm. Could we see the actual pg_attribute data for both this table and
>> its parent?
> Here you are:
Thanks. Nothing particularly strange-looking there though. Do you want
to try tracing through COPY with a debugge
On Wed, 2005-10-12 at 17:45 -0400, Tom Lane wrote:
> Oliver Elphick writes:
> > ... in this particular case, the column
> > order was wrong. I should add that the table inherits from another one,
> > but the swapped columns are a long way into the extra columns specific
> > to this table.
>
> Hm
Oliver Elphick writes:
> ... in this particular case, the column
> order was wrong. I should add that the table inherits from another one,
> but the swapped columns are a long way into the extra columns specific
> to this table.
Hm. Could we see the actual pg_attribute data for both this table
On 10/11/05, incheol yang <[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1953
> Logged by: incheol yang
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.4
> Operating system: fedora core 4
> Description:trigger ac
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Wed, Oct 12, 2005 at 08:23:15PM +0100, Oliver Elphick wrote:
>> I actually use CURRENT_DATE; that is what the system turns it into.
> Ah yes, I see that now. I generally use now(), so I hadn't noticed
> that CURRENT_DATE and CURRENT_TIMESTAMP become '
On Wed, Oct 12, 2005 at 08:17:23PM +0100, Oliver Elphick wrote:
> On Wed, Oct 12, 2005 at 12:19:41PM -0600, Michael Fuhr wrote:
> > Could you post the table definitions?
>
> Here it is:
I created the tables you posted (sans foreign key constraints because
you didn't include the referenced tables
On Wed, Oct 12, 2005 at 08:23:15PM +0100, Oliver Elphick wrote:
> On Wed, 2005-10-12 at 12:13 -0600, Michael Fuhr wrote:
> > On another note, regarding the following:
> >
> > > invdate | date | not null default
> > > ('now'::text)::date
> > > taxpoint | date
On Wed, 2005-10-12 at 12:37 -0600, Michael Fuhr wrote:
> On Wed, Oct 12, 2005 at 12:19:41PM -0600, Michael Fuhr wrote:
> > On Wed, Oct 12, 2005 at 07:08:20PM +0100, Oliver Elphick wrote:
> > > I should add that the table inherits from another one, but the
> > > swapped columns are a long way into t
On Wed, Oct 12, 2005 at 12:19:41PM -0600, Michael Fuhr wrote:
> On Wed, Oct 12, 2005 at 07:08:20PM +0100, Oliver Elphick wrote:
> > I should add that the table inherits from another one, but the
> > swapped columns are a long way into the extra columns specific to
> > this table.
>
> Could you pos
On Wed, Oct 12, 2005 at 11:02:26AM +0100, Eduard Wulff wrote:
> createlang.exe -U postgres -e plperl template1
>
> gives:
> createlang: Installation der Sprache fehlgeschlagen: ERROR: could not load
> library "D:/dapps/PostgreSQL/8.1-beta2/lib/plperl.dll": Das angegebene Modul
> wurde nicht gefun
On Wed, Oct 12, 2005 at 07:08:20PM +0100, Oliver Elphick wrote:
> I should add that the table inherits from another one, but the
> swapped columns are a long way into the extra columns specific to
> this table.
Could you post the table definitions?
--
Michael Fuhr
---(en
On Wed, Oct 12, 2005 at 09:09:05AM +0100, Oliver Elphick wrote:
> Pg 8.0.3 (Debian package) on AMD64, linux 2.6.12
>
> I am importing a table using COPY. The data is tab-delimited. COPY
> seems to be putting the data for one field into the preceding field,
> which should contain the empty string
On Wed, 2005-10-12 at 13:52 -0400, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > Pg 8.0.3 (Debian package) on AMD64, linux 2.6.12
> > I am importing a table using COPY. The data is tab-delimited. COPY
> > seems to be putting the data for one field into the preceding field,
> >
Oliver Elphick <[EMAIL PROTECTED]> writes:
> Pg 8.0.3 (Debian package) on AMD64, linux 2.6.12
> I am importing a table using COPY. The data is tab-delimited. COPY
> seems to be putting the data for one field into the preceding field,
> which should contain the empty string.
Can't reproduce that
On Wed, 2005-10-12 at 09:09 +0100, Oliver Elphick wrote:
> Pg 8.0.3 (Debian package) on AMD64, linux 2.6.12
>
> I am importing a table using COPY. The data is tab-delimited. COPY
> seems to be putting the data for one field into the preceding field,
> which should contain the empty string.
To f
Pg 8.0.3 (Debian package) on AMD64, linux 2.6.12
I am importing a table using COPY. The data is tab-delimited. COPY
seems to be putting the data for one field into the preceding field,
which should contain the empty string.
Here is the data, with tabs indicated by ^I and end of line by $:
67829
The following bug has been logged online:
Bug reference: 1956
Logged by: Karl O. Pinc
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: Linux
Description:Plpgsql top-level DECLARE does not share scope with
CREATE FUNCTION
Details:
Dependi
The following bug has been logged online:
Bug reference: 1957
Logged by: Eduard Wulff
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1 beta2
Operating system: Windows XP SP1 DE
Description:Error for createlang
Details:
I can't add any additional languages e.
Bruce Momjian wrote:
>
> Sorry, I can not understand what you were testing here.
I see now. I am running some tests to try to reproduce it.
---
>
>
Sorry, I can not understand what you were testing here.
---
incheol yang wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1953
> Logged by: incheol yang
> Email address: [EMAIL PRO
25 matches
Mail list logo
