Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
I prepared patch which use oid output function instead regproc output.
This change works only for COPY TO command.
This is not a bug and we're not going to fix it, most especially not
Zdenek Kotala wrote:
> Tom Lane napsal(a):
> >Zdenek Kotala <[EMAIL PROTECTED]> writes:
> >>I prepared patch which use oid output function instead regproc output.
> >>This change works only for COPY TO command.
> >
> >This is not a bug and we're not going to fix it, most especially not
> >like tha
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
I prepared patch which use oid output function instead regproc output.
This change works only for COPY TO command.
This is not a bug and we're not going to fix it, most especially not
like that.
OK, The behavior of regproc type i
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I prepared patch which use oid output function instead regproc output.
> This change works only for COPY TO command.
This is not a bug and we're not going to fix it, most especially not
like that.
regards, tom lane
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Hmm, maybe it should be using regprocedure instead?
Not unless you want to break initdb. The only reason regproc still
exists, really, is to accommodate loading of pg_type during initdb.
Guess what: we can't do type lookup at that poi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> I'm not sure if it is important, but I think that preserve OID is
>> important and SQL level does not allow set OID.
> Does it matter in any case other than where it refers to an on-disk
> object? And does that need anything ot
Zdenek Kotala wrote:
Tom Lane wrote:
The right way to implement pg_upgrade is to transfer the catalog data
at the SQL-command level of abstraction, ie, "pg_dump -s" and reload.
I'm not sure if it is important, but I think that preserve OID is
important and SQL level does not allow set OID.
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
I'm playing with catalog upgrade. The very basic idea of my experiment
is export data from catalog and import it back to the new
initialized/fresh catalog.
That is never going to work, at least not for any interesting catalogs.
A syste
Zdenek Kotala <[EMAIL PROTECTED]> writes:
>if( donot_resolve_procname == TRUE)
>{
> result = (char *) palloc(NAMEDATALEN);
> snprintf(result, NAMEDATALEN, "%u", proid);
>}
What for? If you want numeric OIDs you can have that today by casting
the column to OID. More to the
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I'm playing with catalog upgrade. The very basic idea of my experiment
> is export data from catalog and import it back to the new
> initialized/fresh catalog.
That is never going to work, at least not for any interesting catalogs.
A system with a "fre
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Hmm, maybe it should be using regprocedure instead?
Not unless you want to break initdb. The only reason regproc still
exists, really, is to accommodate loading of pg_type during initdb.
Guess what: we can't do type lookup at that poi
Zdenek Kotala wrote:
Andrew Dunstan wrote:
Zdenek Kotala wrote:
I tried to use COPY command to export and import tables from catalog
Is it just me or does this seem like a strange thing to want to do? I
am trying to think of a good use case, so far without much success.
I'm playing with
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Hmm, maybe it should be using regprocedure instead?
>
> Not unless you want to break initdb. The only reason regproc still
> exists, really, is to accommodate loading of pg_type during initdb.
> Guess what: we can't do type lookup a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm, maybe it should be using regprocedure instead?
Not unless you want to break initdb. The only reason regproc still
exists, really, is to accommodate loading of pg_type during initdb.
Guess what: we can't do type lookup at that point.
Andrew Dunstan wrote:
Zdenek Kotala wrote:
I tried to use COPY command to export and import tables from catalog
Is it just me or does this seem like a strange thing to want to do? I am
trying to think of a good use case, so far without much success.
I'm playing with catalog upgrade. The
Zdenek Kotala wrote:
> I tried to use COPY command to export and import tables from catalog,
> but COPY command has problem with data type regproc. See example
>
> create table test (like pg_aggregate);
> copy pg_aggregate to '/tmp/pg_agg.out';
> copy test from '/tmp/pg_agg.out';
>
> ERROR
Zdenek Kotala wrote:
I tried to use COPY command to export and import tables from catalog
Is it just me or does this seem like a strange thing to want to do? I am
trying to think of a good use case, so far without much success.
cheers
andrew
---(end of broadcast)--
I tried to use COPY command to export and import tables from catalog,
but COPY command has problem with data type regproc. See example
create table test (like pg_aggregate);
copy pg_aggregate to '/tmp/pg_agg.out';
copy test from '/tmp/pg_agg.out';
ERROR: more than one function named "pg_
18 matches
Mail list logo
