Re: [HACKERS] schema_to_xmlschema() seems a bit less than finished
On 7/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
In the regression database:
regression=# select schema_to_xmlschema('public',false,false,'foo');
ERROR: cache lookup failed for type 0
I have no idea what this function should produce, but surely not that?
regards, tom lane
The following test case reproduces the problem:
create domain domtxt as text;
create table dom_tab(col1 domtxt);
drop domain domtxt cascade;
select schema_to_xmlschema('public',false,false,'foo');
Since domtxt domain is being dropped dom_tab should not contain any columns now.
However It appears that the tuple descriptor which
map_sql_typecoll_to_xmlschema_types() (in xml.c) gets for dom_tab
still shows one column (tupdesc->natts = 1). Subsequently when
SPI_gettypeid() is invoked it returns 0, which gets inserted in the
uniquetypes list.
Since the following foreach statement simply traverses the uniquetypes
list and invokes getBaseType() on its oid values, therefore 0 gets
passed to getBaseType() which results in the "cache lookup failed
..." error.
Considering the above fact, perhaps the actual problem is that when a
column gets removed from a table as a result of drop cascade, the tuple descriptor (more specifically
rel->rd_att field) for that relation is not updated properly?
regards,
--
Sibte Abbas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] [GENERAL] 8.2.4 signal 11 with large transaction
On 7/20/07, Tom Lane <[EMAIL PROTECTED]> wrote: I guess what we need to do is hack the emergency-recovery path for error-during-error-processing such that it will prevent trying to print a very long debug_query_string. Maybe we should just not try to print the command at all in this case, or maybe there's some intermediate possibility like only printing the first 1K or so. Thoughts? regards, tom lane I think printing the first 1K would make more sense. If I understand you correctly, the code path which you are referring to is the send_message_to_server_log() function in elog.c? thanks, -- Sibte Abbas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [GENERAL] 8.2.4 signal 11 with large transaction
On 7/23/07, Tom Lane <[EMAIL PROTECTED]> wrote: No, the place that has to change is where errstart() detects that we're recursing. We could possibly have it first try to make a shorter string and only give up entirely if recursion happens again, but given that this is such a corner case I don't think it's worth the complexity and risk of further bugs. I've made it just drop the statement at the same time that it decides to give up on printing other context (which can also be a source of out-of-memory problems btw). http://archives.postgresql.org/pgsql-committers/2007-07/msg00215.php Makes sense. regards, -- Sibte Abbas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] TODO item: add \# which lists line numbers, and allows command execution
Hi all, Realizing that the mentioned TODO item discussed at http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php<http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php>can be useful for myself and others as well, I would like to go ahead and implement it. Synopsis: == Sticking to the syntax and semantics which Joshua already mentioned in the thread: \#: displays the command history. Like \s but prefixes the lines with line numbers \# : executes the command(if any) executed at the line specified by line_no Display the history contents: = Well the answer to this pretty much lies in the \s (without any filename) implementation. However \s simply writes the contents of the history to the TTY while \# would prefix all the history lines with their respective line numbers. Because of this difference, we'll have to employ a more flexible approach rather than simply using the write_history() function. A solution to this is to use history_list() function to get a list of HIST_ENTRY structures and simply display them as per our needs i.e. to prefix each line with incrementing numbers in our case. Execute a line based on line number: == For this we can simply use the history_get(int offset) function of the gnu history api to return a HIST_ENTRY structure corresponding to the given offset. The returned HIST_ENTRY can then be used to access the command that was executed at that specific line number. Comments are welcomed. regards, -- Sibte Abbas
Re: [HACKERS] TODO item: add \# which lists line numbers, and allows command execution
On 9/8/07, Sibte Abbas <[EMAIL PROTECTED]> wrote: > > > Hi all, > > Realizing that the mentioned TODO item discussed at > http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php > <http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php> can be > useful for myself and others as well, I would like to go ahead and implement > it. > > Synopsis: > == > > Sticking to the syntax and semantics which Joshua already mentioned in the > thread: > > \#: displays the command history. Like \s but prefixes the lines with line > numbers > > \# : executes the command(if any) executed at the line specified > by line_no > > > Display the history contents: > = > > Well the answer to this pretty much lies in the \s (without any filename) > implementation. However \s simply writes the contents of the history to the > TTY while \# would prefix all the history lines with their respective line > numbers. > > Because of this difference, we'll have to employ a more flexible approach > rather than simply using the write_history() function. > > A solution to this is to use history_list() function to get a list of > HIST_ENTRY structures and simply display them as per our needs i.e. to > prefix each line with incrementing numbers in our case. > > Execute a line based on line number: > == > > For this we can simply use the history_get(int offset) function of the gnu > history api to return a HIST_ENTRY structure corresponding to the given > offset. > > The returned HIST_ENTRY can then be used to access the command that was > executed at that specific line number. > > Comments are welcomed. > > regards, > -- > Sibte Abbas > Patch submitted to pgsql-patches. regards, -- Sibte Abbas
Re: [HACKERS] Raw device I/O for large objects
On 9/17/07, Georgi Chulkov <[EMAIL PROTECTED]> wrote: > > Could someone please point me to the right places to look at, and how/where to > get started? Would such a development be useful at all? Is anyone working on > anything related? > > Any feedback / information would be highly appreciated! > http://www.postgresql.org/docs/techdocs http://www.postgresql.org/docs/faq/ The postgresql documentation: http://www.postgresql.org/docs/8.2/interactive/index.html Also, If you have the source, the src/tools/backend directory has some useful material for starters. regards, -- Sibte Abbas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] NULL and plpgsql rows
On 10/2/06, Tom Lane <[EMAIL PROTECTED]> wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > However, the test right above that means that we'll fail if the user > > tries something like "row_variable := NULL;": > > The patch you seem to have in mind would allow > row_variable := int_variable; > to succeed if the int_variable chanced to contain NULL, which is surely > not very desirable. > > The real issue here is that the bare NULL has type UNKNOWN and we're not > making any effort to cast it. I'm not sure whether it'd work to simply > apply exec_cast_value --- that looks like it's only meant to handle > scalars, where in general you'd need something close to > ExecEvalConvertRowtype(). > > > Of course, setting a row variable to null is a lot more useful if we can > > actually test for it after the fact, and I'm not really sure how to make > > that happen. > > Doesn't IS NULL work (as of CVS HEAD)? > Is there a specific reason why we keep the tuple descriptor of an unassigned record type to NULL? Surely we don't know what tuple descriptor it will actually contain, however, maybe we can have "special" tuple descriptors for un-assigned record types. For example, if for NULL/unassigned record type we create a tuple descriptor of "VOID" type, and then initialize its corresponding (one column) row to null, we 'll have the IS NULL check working on unassigned or NULL record types as well. regards, -- Sibte Abbas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] psql slash# command
On Sun, Mar 30, 2008 at 3:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > > I looked this over and realized that it has little to do with the > functionality that was so painfully hashed out in the original > discussion thread here: > > http://archives.postgresql.org/pgsql-hackers/2006-12/msg00207.php > > As I understood it, the consensus was: > > 1. Invent a switch (probably a variable instead of a dedicated \-command) > that determines whether \s includes command numbers in its output. > > 2. Add "\# n" to re-execute command number n. > > You've twisted this around into > > >> \#: displays the command history. Like \s but prefixes the lines with > line > >> numbers > >> > >> \# : executes the command(if any) executed at the line > specified by > >> line_no > This patch implements the specification described here: http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php > > > This is a serious regression in functionality from what was agreed to, > because there is no possibility of shoehorning the equivalent of "\s file" > into it --- you've already decided that any argument is a line number. It made sense to assume anything following a \# to be a number, since "#" here denotes a number. However in order to prevent from bad input, there is a check in the get_hist_entry() function. > > The attached patch adds the following new functionality: > > \#e : Will open the command at the given lineno in an editor. > > \#e with no lineno will behave exactly like \e. > > None of that was anywhere in the original discussion; and what pray > tell is the use of the second variant? The above mentioned link contains definitions for both of these. Also the second variant here is just for completeness sake. > I wonder whether it wouldn't be safer and more convenient if we defined > '\# n' as pulling command n into the edit buffer, rather than > immediately executing it. Actual execution is only a away, > but this definition would allow you to edit the command a bit more > before you execute it --- including \e to use an editor. It also > closes the loop in terms of providing some confidence that you typed > the number you should have typed. > This makes more sense and also appears to be much safer. I will start modifying the patch as per this approach now. regards, -- Sibte Abbas
Re: [HACKERS] psql slash# command
On Sat, Apr 5, 2008 at 12:36 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > > Actually, I suggested that to the patch author and he accepted it as a > good idea: > http://archives.postgresql.org/pgsql-hackers/2008-04/msg00245.php > > so let's see what he comes up with... > > New patch submitted: http://archives.postgresql.org/pgsql-patches/2008-04/msg00240.php regards, -- Sibte Abbas
